- linaro-toolchain - lists.linaro.org

by Riku Voipio

Hi, As painfully found out by mono team, if big/little cores have different cache line sizes, __clear_cache doesn't work as expected. This affects any home-grown cache flushing mechanism as well. http://www.mono-project.com/news/2016/09/12/arm64-icache/ protip, if you suspect your application issues might related to big.LITTLE, use taskset(1) or hwloc-bind(1) to tie the process to either big or little cluster (or just a single core).

9 years, 7 months

2
1
0 0

[Activity] 5 - 8 Sept 2016

by Peter Smith

== Progress == - Still trying to get support for .ARM.exidx into upstream LLD, looks like more changes are needed by the owners, but I think I should be able to get this by the next report. - LLVM Cauldron on Thursday. Trip report sent separately - Holiday on Friday == Next week == Planned: - ARM Exceptions support in lld - Further lld porting work

9 years, 7 months

1
0
0 0

[ACTIVITY] 5-9 Sept 2016

by kugan

== Progress == - Connect slides - Analyzed IPA-VRP performance for slides - Started working on return jump function - Reading C++ ABI and other documents referred in Honza's blog to understand the C++ related issues in IPA/LTO = Next == - Work on IPA/LTO improvements - Benchmarking - Follow up on pending patches

9 years, 7 months

1
0
0 0

[ANNOUNCE] Linaro GCC 6 2016.09 snapshot

by Yvan Roux

The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2016.09 snapshot of the Linaro GCC 6 source package. This monthly snapshot[1] is based on FSF GCC 6.2+svn239654 and includes performance improvements and bug fixes backported from mainline GCC. This snapshot contents will be part of the 2016.11 stable[2] quarterly release. This snapshot tarball is available on: http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.2-2016.09/ Interesting changes in this GCC source package snapshot include: * Backport of [Bugfix] [AArch32] PR target/53440 Handle generic thunks better for TARGET_32BIT * Backport of [Bugfix] [AArch32] PR target/59833 ARM soft-float extendsfdf2 fails to quiet signaling NaN * Backport of [Bugfix] [AArch32] PR target/70473 Reduce size of Cortex-A8 automaton * Backport of [Bugfix] [AArch32] PR target/71061 length pop* pattern in epilogue correctly * Backport of [Bugfix] [AArch32] PR target/77281 Fix an invalid check for vectors of the same floating-point constants. * Backport of [Bugfix] [AArch64] PR 64971 Convert function pointer to Pmode when emit call. * Backport of [Bugfix] [AArch64] PR 70904 Relax the restriction on subreg reload for wide mode * Backport of [Bugfix] [AArch64] PR target/63596 Honor tree-stdarg analysis result to improve VAARG codegen * Backport of [Bugfix] [AArch64] PR target/63874 vtable address generation goes through memory * Backport of [Bugfix] PR 70751 Correct the cost for spilling non-pseudo into memory * Backport of [Bugfix] PR 77421 Redundant second assignment of bb_copy = NULL in free_original_copy_tables * Backport of [Bugfix] PR middle-end/37780 Conditional expression with __builtin_clz() should be optimized out * Backport of [Bugfix] PR middle-end/68217 Wrong constant folding * Backport of [Bugfix] PR middle-end/71700 zero-extend sub-word value when widening constructor element * Backport of [Bugfix] PR rtl-optimization/66940 Avoid signed overflow in noce_get_alt_condition * Backport of [Bugfix] PR rtl-optimization/71150 Guard in_class_p with REG_P check * Backport of [Bugfix] PR rtl-optimization/71295 * Backport of [Bugfix] PR rtl-optimization/71594 ICE in noce_emit_cmove due to mismatched source modes * Backport of [Bugfix] PR rtl-optimization/71878 * Backport of [Bugfix] PR tree-optimization/61839 More optimize opportunity for VRP * Backport of [Bugfix] PR tree-optimization/71818 ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize * Backport of [AArch32] Keep ctz expressions together until after reload * Backport of [AArch32] Add fcsel to Cortex-A57 scheduler * Backport of [AArch32] Add initial support for Cortex-A73 * Backport of [AArch32] Add support for overflow add, sub, and neg operations * Backport of [AArch32] Add support for some ARMv8-A cores to driver-arm.c * Backport of [AArch32] arm_neon.h: s/__FAST_MATH/__FAST_MATH__/g * Backport of [AArch32] Emit vmov.i64 to load 0.0 into FP reg when neon enabled. * Backport of [AArch32] Enable __fp16 as a function parameter and return type * Backport of [AArch32] Fix aprofile multilib mappings * Backport of [AArch32] Fix predicable_short_it attribute for arm_movqi_insn * Backport of [AArch32] genmultilib: improve error reporting for MULTILIB_REUSE * Backport of [AArch32] improve Cortex-A53 integer scheduler * Backport of [AArch32] Model CSEL instruction in Cortex-A57 scheduling model * Backport of [AArch32] no-data-is-text-relative & msingle-pic-base * Backport of [AArch32] Refactor MOVW/MOVT fusion logic to allow extension * Backport of [AArch32] Replace uses of int_log2 by exact_log2 * Backport of [AArch32] Update documentation for ARM architecture * Backport of [AArch32] Use a MULTILIB_REQUIRED approach for aprofile multilib * Backport of [AArch64] 1/2 Add support INS (element) instruction to copy lanes between vectors * Backport of [AArch64] 2/2 (Re)Implement vcopy<q>_lane<q> intrinsics * Backport of [AArch64] 1/2 Improve zero extend * Backport of [AArch64] 2/2 Improve zero extend * Backport of [AArch64] 1/3 Migrate aarch64_add_constant to new interface & kill aarch64_build_constant * Backport of [AArch64] 2/3 Optimize aarch64_add_constant to generate better addition sequences * Backport of [AArch64] 3/3 Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant * Backport of [AArch64] 1/6 Reimplement scalar fixed-point intrinsics * Backport of [AArch64] 2/6 Reimplement vector fixed-point intrinsics * Backport of [AArch64] 3/6 Reimplement frsqrte intrinsics * Backport of [AArch64] 4/6 Reimplement frsqrts intrinsics * Backport of [AArch64] 5/6 Reimplement fabd intrinsics & merge rtl patterns * Backport of [AArch64] 6/6 Reimplement vpadd intrinsics & extend rtl patterns to all modes * Backport of [AArch64] Accept vulcan as a cpu name for the AArch64 port of GCC * Backport of [AArch64] Add ANDS pattern for CMP+ZERO_EXTEND * Backport of [AArch64] Add commit message * Backport of [AArch64] Add initial support for Cortex-A73 * Backport of [AArch64] Add legitimize_address_displacement hook * Backport of [AArch64] Add more choices for the reciprocal square root approximation * Backport of [AArch64] Add rtx_costs routine for vulcan * Backport of [AArch64] Add some more missing intrinsics * Backport of [AArch64] Add ThunderX vector cost model * Backport of [AArch64] Allow multiple-of-8 immediate offsets for TImode LDP/STP * Backport of [AArch64] Canonicalize Cortex core tunings * Backport of [AArch64] Cleanup -mpc-relative-loads * Backport of [AArch64] Define WORD_REGISTER_OPERATIONS to zero and comment why * Backport of [AArch64] Emit division using the Newton series * Backport of [AArch64] Emit square root using the Newton series * Backport of [AArch64] Enable tree-stdarg pass for AArch64 by defining counter fields * Backport of [AArch64] Fix typo in aarch64_legitimize_address * Backport of [AArch64] Fixup to fcvt patterns added in r237200 * Backport of [AArch64] Fix vld2/3/4 on big endian systems * Backport of [AArch64] Give some new costs for Cortex-A53 floating-point operations * Backport of [AArch64] Give some new costs for Cortex-A57 floating-point operations * Backport of [AArch64] Handle AND+ASHIFT form of UBFIZ correctly in costs * Backport of [AArch64] Handle iterator definitions with conditionals in geniterator.sh * Backport of [AArch64] Improve aarch64_modes_tieable_p * Backport of [AArch64] Increase code alignment * Backport of [AArch64] Keep CTZ components together until after reload * Backport of [AArch64] Optimize prolog/epilog * Backport of [AArch64] Remove aarch64_cannot_change_mode_class * Backport of [AArch64] Remove spurious attribute __unused__ from NEON intrinsic * Backport of [AArch64] Renaming ARMv8.1 to ARMv8.1-A in comments and documentations * Backport of [AArch64] Replace insn to zero up SIMD registers * Backport of [AArch64] update vulcan L1 cacheline size * Backport of [ARMv8.2] [AArch64] 10/10 ARMv8.2-A FP16 lane scalar intrinsics * Backport of [ARMv8.2] [AArch64] 1/10 ARMv8.2-A FP16 data processing intrinsics * Backport of [ARMv8.2] [AArch64] 2/10 ARMv8.2-A FP16 one operand vector intrinsics * Backport of [ARMv8.2] [AArch64] 3/10 ARMv8.2-A FP16 two operands vector intrinsics * Backport of [ARMv8.2] [AArch64] 4/10 ARMv8.2-A FP16 three operands vector intrinsics * Backport of [ARMv8.2] [AArch64] 5/10 ARMv8.2-A FP16 lane vector intrinsics * Backport of [ARMv8.2] [AArch64] 6/10 ARMv8.2-A FP16 reduction vector intrinsics * Backport of [ARMv8.2] [AArch64] 7/10 ARMv8.2-A FP16 one operand scalar intrinsics * Backport of [ARMv8.2] [AArch64] 8/10 ARMv8.2-A FP16 two operands scalar intrinsics * Backport of [ARMv8.2] [AArch64] 9/10 ARMv8.2-A FP16 three operands scalar intrinsics * Backport of [ARMv8.2] [AArch64] ARMv8.2 command line and feature macros support * Backport of [Misc] 1/2 Move choose_mult_variant declaration and dependent declarations to expmed.h * Backport of [Misc] 2/2 Hook up mult synthesis logic into vectorisation of mult-by-constant * Backport of [Misc] Append "evaluates to 0" for Wundef diagnostic * Backport of [Misc] Avoid unnecessary peeling for gaps with LD3 * Backport of [Misc] Check for POINTER_TYPE_P before accessing SSA_NAME_PTR_INFO in tree-inline * Backport of [Misc] Disable ifunc on *-musl by default * Backport of [Misc] Disable setting param of __builtin_constant_p to null * Backport of [Misc] Don't count spilling cost for it offmemok * Backport of [Misc] Don't use section anchors for declarations that don't fit in a single anchor range * Backport of [Misc] Fix ChangeLog entry * Backport of [Misc] Fix GROUP_GAP for single-element interleaving * Backport of [Misc] Fix unused variable warning in simplify_cond_clz_ctz on some targets * Backport of [Misc] Increase alignment of global structs in increase_alignment pass * Backport of [Misc] Latent alignment bug in tree-ssa-address.c * Backport of [Misc] Report supported function classes correctly on *-musl * Backport of [Testsuite] 29_atomics/atomic/65913.cc: require atomic-builtins rather than specific target * Backport of [testsuite] [AArch32] Add missing guards to fp16 AdvSIMD tests * Backport of [Testsuite] [AArch32] Fix, add tests for FP16 aapcs * Backport of [Testsuite] [AArch32] Fix dg-do and dg-skip order * Backport of [Testsuite] [AArch32] gcc.target/arm/pr37780_1.c: Use arm_arch_v6t2 effective target and options * Backport of [Testsuite] [AArch32] Make arm_neon_fp16 depend on arm_neon_ok * Backport of [Testsuite] [AArch32] Selectors and options directives for ARM VFP FP16 support * Backport of [Testsuite] [AArch64] Ensure vrnd* tests run on ARMv8 cores * Backport of [Testsuite] Add testcases * Backport of [testsuite] asan/clone-test-1.c: Handle clone() failure * Backport of [Testsuite] Fix testcases * Backport of [Testsuite] Use setrlimit for testing libstdc++ in cross toolchains * Backport of [Cleanup] [AArch32] 2/4 Replace casts of 1 to HOST_WIDE_INT by HOST_WIDE_INT_1 and HOST_WIDE_INT_1U * Backport of [Cleanup] [AArch32] 3/4 Cleanup casts from INTVAL to [unsigned] HOST_WIDE_INT * Backport of [Cleanup] [AArch32] 4/4 Simplify checks for CONST_INT_P and comparison against 1/0 * Backport of [cleanup] [AArch32] Delete thumb_reload_in_h * Backport of [Cleanup] [AArch32] Remove non-existent extern declarations in arm.h * Backport of [Cleanup] [AArch64] aarch64_elf_asm_named_section: Remove declaration. * Backport of [Cleanup] [AArch64] Clean up parentheses and use GET_MODE_UNIT_BITSIZE in a couple of patterns * Backport of [Cleanup] [AArch64] Remove static variable all_extensions from aarch64.c * Backport of [Cleanup] Cleanup frame push/pop code * Backport of [Cleanup] rtlanal.c: Convert conditional compilation on WORD_REGISTER_OPERATIONS * Backport of [Debug] ifcvt: Print name of noce trasform that succeeded in dump file Subscribe to the important Linaro mailing lists and join our IRC channels to stay on top of Linaro development. ** Linaro Toolchain Development "mailing list": http://lists.linaro.org/mailman/listinfo/linaro-toolchain ** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@ * Bug reports should be filed in bugzilla against GCC product: http://bugs.linaro.org/enter_bug.cgi?product=GCC * Interested in commercial support? inquire at "Linaro support": mailto:support@linaro.org [1]. Source package snapshots are defined when the compiler is only put through unit-testing and full validation is not performed. [2]. Stable source package releases are defined as releases where the full Linaro Toolchain validation plan is executed.

9 years, 8 months

1
0
0 0

Question on "Using deprecated CP15 barrier instruction".

by stimits＠comcast.net

Hi, For reference, the following questions refer to a Linux 3.10 aarch64 kernel (ARMv8, ARMv8-A) compiled with Linaro 5.3-2016.02 (5.3-2016.02 arm64 CROSS_COMPILE and 5.3-2016.02 armhf CROSS32CC cross compiled from x86_64). This Linux kernel compile requires the full 64-bit tool chain plus the 32-bit gcc. There is a Linux kernel file "arch/arm64/kernel/deprecated.c". Within that file is a block of code which is apparently designed to detect some sort of older obsolete 32-bit code. Specifically, the warning message is "Using deprecated CP15 barrier instruction". I wouldn't think that this kernel, when compiled with such a recent compiler, would ever introduce CP15 barrier code (from what I see barrier code was deprecated in ARMv7 and used to deal with obsolete ARMv6 code). Is there any chance the 32-bit 5.3 gcc would still generate CP15 barrier code? Although this kernel and "most" modules are built with Linaro 5.3 I'd like to be able to narrow the cause down to existing binary modules not compiled with the 5.3 Linaro. If I can guarantee 5.3 32-bit gcc does not produce the CP15 barrier instruction then I'll know it is in pre-built binary modules. Can anyone tell me if C code compiled from Linaro version 5.3 32-bit gcc code would ever contain CP15 instructions? Thanks!

9 years, 8 months

3
2
0 0

RE: Question on "Using deprecated CP15 barrier instruction".

by stimits＠comcast.net

What I need to confirm is if the Linaro 5.3 would generate such code from a normal block of C without any kind of asm in it? Detecting the code is part of the kernel...I need to figure out where it was generated. Is Linaro 5.3 going to generate such code without explicitly writing it in? ----- Original Message -----From: Andrew Pinski <Andrew.Pinski(a)cavium.com>To: stimits(a)comcast.net, Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>Sent: Mon, 05 Sep 2016 17:21:24 -0000 (UTC)Subject: RE: Question on "Using deprecated CP15 barrier instruction". Simple answer is yes. There are a lot of assembly out there and someone (seen it in the past) could have used this barrier method in their code and not really thought it was going to change in the future. Thanks, Andrew From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org]On Behalf Of stimits(a)comcast.netSent: Monday, September 5, 2016 8:10 AMTo: Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>Subject: Question on "Using deprecated CP15 barrier instruction". Hi, For reference, the following questions refer to a Linux 3.10 aarch64 kernel (ARMv8, ARMv8-A) compiled with Linaro5.3-2016.02 (5.3-2016.02 arm64 CROSS_COMPILE and 5.3-2016.02 armhf CROSS32CC cross compiled from x86_64). This Linux kernel compile requires the full 64-bit tool chain plus the 32-bit gcc. There is a Linux kernel file "arch/arm64/kernel/deprecated.c". Within that file is a block of code which is apparently designed to detect some sort of older obsolete 32-bit code. Specifically, the warning message is "Using deprecated CP15 barrier instruction". I wouldn't think that this kernel, when compiled with such a recent compiler, would ever introduce CP15 barrier code (from what I see barrier code was deprecated in ARMv7 and used to deal with obsolete ARMv6 code). Is there any chance the 32-bit 5.3 gcc would still generate CP15 barrier code? Although this kernel and "most" modules are built with Linaro 5.3 I'd like to be able to narrow the cause down to existing binary modules not compiled with the 5.3 Linaro. If I can guarantee 5.3 32-bit gcc does not produce the CP15 barrier instruction then I'll know it is in pre-built binary modules. Can anyone tell me if C code compiled from Linaro version 5.3 32-bit gcc code would ever contain CP15 instructions? Thanks!

9 years, 8 months

2
1
0 0

[ACTIVITY] Week 35

by Yvan Roux

== Progress == o Linaro GCC/Validation (7/10) - Merged bkk16 buildfarm developments into main job. - Backports: Reviews, dependencies tracking and backports. - Analysed extended validation results. o Misc (3/10) * Various meetings and discussions. == Plan == o Release 2016.09 Snapshots o GNU Cauldron

9 years, 8 months

1
0
0 0

[ACTIVITY] 29 August-2 Sept 2016

by Kugan Vivekanandarajah

== Progress == - IPA-VRP: Re-based ipa-cp/ipa-prop on top of Prathameshes commit (quite a few conflicts) and did full testing before posting to the list. Patch approved for commit. - Waiting for Early-VRP patch to commit rest of the patches in the series - All other patches are OK now. - Looking at tree-vrp in details. Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77387 - Looking at re-assoc wrong code generation issue (PR72835). Posted another attempt to fix for review = Next == - Work on tree-vrp improvements - Follow up on pending patches

9 years, 8 months

1
0
0 0

[ACTIVITY] 29 August-2 Sept 2016

by Christophe Lyon

1 day off (Wed) == Progress == * Validation - patch reviews (Jenkins jobs, abe) - infra seems very stable * GCC Snapshot - backports & reviews * GCC - progress on PR 67591 (ARM v8 Thumb IT blocks deprecated) = Next == - monitor GCC trunk regressions - GCC pr 67591 - release scripts/abe - backports/reviews - attend GNU Cauldron

9 years, 8 months

1
0
0 0

[ACTIVITY] 29 August - 2 September 2016

by Prathamesh Kulkarni

== This Week == * TCWG-779 (4/10) - Upstream patch iterations * NULL pointer propagation in ipa-bitwise-cp (4/10) - WIP patch * Benchmarking (1/10) - Found how to set iterations for coremark - Submitted job for setting up hack session on Juno * Misc (1/10) - Meetings == Next Week == - NULL pointer propagation - TCWG-779 - GNU Cauldron

9 years, 8 months

1
0
0 0

[ACTIVITY] 30 Aug -2 Sep 2016

by Yao Qi

* Holiday on Monday. [2/10] # Progress # * TCWG-685, GDB 7.12 release. No new issue. [1/10] * TCWG-655, ARM linux kernel ptrace bug. [3/10] Teach GDB testsuite to detect such kernel bug, and skip all tests related to floating point. Patches are committed. On the other hand, upgrade my arm kernel to 4.7.2, on which the ptrace bug is fixed. * TCWG-518, range stepping on ARM. [2/10]. Turned it on, but it causes some threads starvation. Investigating. * Finish the reproducer to show odd behaviour of armv8 kernel in si_code after PTRACE_SINGLESTEP and Will Deacon fixed it http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/453289… [1/10] * Think about the GDB plan, and write down a list of things I need to do. [1/10] # Plan # * TCWG-685, TCWG-518. * GNU Cauldron. -- Yao Qi

9 years, 8 months

1
0
0 0

[ACTIVITY] 30-2 September 2016

by Peter Smith

== Activity == [TCWG-610] Sent .ARM.exidx for upstream review. Will need to rework and simplify bit to make more specific to ARM. In summary abandon pretence of SHF_LINK_ORDER in general and concentrate on supporting its one known use case in .ARM.exidx sections. Made a couple of drafts of forthcoming LLVM Cauldron presentation - Presented locally - Modified slides after overrunning time == Plans == [TCGWG-610] Rework and resend for review llvm-cauldron on Thursday Intending to take Friday as holiday to take advantage of visiting parents whilst up North.

9 years, 8 months

1
0
0 0

[ACTIVITY] 22-26 August 2016

by Christophe Lyon

== Progress == * Validation - patch reviews (Jenkins jobs, abe) mainly for the release process * Backports - resubmitted the pending ones - started looking at v8.2 backports * GCC - resumed PR 67591 (ARM v8 Thumb IT blocks deprecated) * arm-neon-tests - small update to support clang, as requested by Chromium * misc (conf-calls, meetings, emails, ....) - catching up after holidays == Next == - monitor trunk regressions - pr 67591 - release scripts - backports

9 years, 8 months

1
0
0 0

[ACTIVITY] Week 34

by Yvan Roux

== Progress == o Linaro GCC/Validation (7/10) - Reviewed on-going Backports. - Analysis on remaining backports dependencies on-going. - Merged FSF GCC 6 branch. - Last FSF GCC 4.9 merge still on-going (some conflicts to solve). - Defining and experimenting new revisions/backports tracking format in yaml. o Misc (3/10) * Various meetings and discussions. == Plan == o FInish backports, and FSF branch merge for next week snapshot.

9 years, 8 months

1
0
0 0

[ACTIVITY] 22 - 26 August 2016

by Prathamesh Kulkarni

== This Week == * TCWG-666 (2/10) - Martin confirmed the assert was spurious that caused some obj-c tests to fail, removing it passes bootstrap+test. - Changed option name to -fipa-bit-cp following Honza's suggestion - Committed as r239769. * TCWG-779 (4/10) - Patch iterations based on upstream suggestions. * Public Holiday (2/10) * Misc (2/10) - Background reading on mod/ref analysis - Meetings

9 years, 8 months

1
0
0 0

[ACTIVITY] 22 - 26 August 2016

by Yao Qi

# Progress # * TCWG-685, GDB 7.12 release. [4/10] Finish all native testing on ARM. Triaged tests result. Only find one fail that test assumes HW watchpoint is always available. Reported it upstream, but need more thoughts on how to fix it. Both AArch64 and ARM GDB is in a good state, in terms of test results. * TCWG-533, Remove global variable arm_override_mode. [2/10] It is paused by 7.12 release, and work on it again. 10 patches are ready. Being regression tested. * Analyse the kernel behaviour on single step over fork. [4/10] Upgrade juno kernel to 4.7.0-rc4+, and verified Will Deacon's patch. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/451711.ht… With the patch, GDB can correctly single step over fork, however, GDB is still broken if there is a breakpoint. Write a small reproducer, but doesn't trigger the problem. It might be a GDB bug or kernel bug. # Plan # * Resume works interrupted by 7.12 release. -- Yao Qi

9 years, 8 months

1
0
0 0

[ACTIVITY] 22 - 26 August 2016

by Peter Smith

== Progress == - Got back from Sabbatical and caught up with email/events - TCWG-610 Support for ARM Exceptions in lld. Implemented support for SHF_LINK_ORDER and .ARM.exidx in lld, have this working and tested for images (both with default and linker scripts) and relocatable ld -r with the default layout. Currently it looks like relocatable outputs with linker scripts aren't working at all right now. == Plan == - Hope to send to upstream review next week. - Write the first pass of the LLVM Cauldron presentation. == Planned absence == Monday 29th August is UK national holiday

9 years, 8 months

1
0
0 0

[ACTIVITY] 22 - 26 August 2016

by Diana Picus

== Progress == * [AArch64] Support for label arithmetic in the assembler [TCWG-710] [9/10] - Patch in upstream review - While adding more tests for the patch above, I noticed that we're not encoding the lsl #12 on add/sub immediates correctly - Submitted a patch to fix that as well * Misc [1/10] - Ran more precommit tests for last week's reverted revisions == Plan == * Handle special cases in AArch64InstrInfo::GetInstSizeInBytes [TCWG-757]

9 years, 8 months

1
0
0 0

[ACTIVITY] 15 - 19 Aug

by Yao Qi

* Two days off [4/10] # Progress # * TCWG-685, GDB 7.12 release. [3/10] Fix one bug that AArch64 GDB doesn't recognize new "STP with base register" instruction in prologue. Recent GCC https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html starts to generate that instruction in prologue. Fix it in both master and 7.12. Successfully build armhf toolchain with latest gcc/glibc. Run GDB tests with the new toolchain. Test results are OK, except fails when tests are compiled with -march=cortex-a15. It isn't a release blocker. Open TCWG-756 for it and will look into these fails later. * GDBserver build failure. [1/10] Review the patch fixing GDBserver build failure with latest glibc. Patch is OK, but make sure it can be merged to master/7.12/7.11, as we are still using GDB 7.11. * Prelink. [1/10] prelink causes some GDB tests failures, so I look at it. prelink isn't active, because I can't see any mails in archive since 2013. ARM is supported, but AArch64 isn't. * Misc, [1/10]. Set up email 2fa. # Plan # * GDB 7.12 release. * Upgrade the linux kernel on my juno board. -- Yao Qi

9 years, 8 months

1
0
0 0

[ACTIVITY] 15 - 19 August 2016

by Diana Picus

== Progress == * LLVM 3.9.0 Release for AArch64 [TCWG-696] [1/10] - Ran the tests for RC2, everything looks good on AArch64 * [AArch64] Support for label arithmetic in the assembler [TCWG-710] [3/10] - This is starting to look like a patch, but I need to add more tests * Buildbot babysitting [TCWG-716, 719, 720] [5/10] - Bisected a number of failures and reverted some patches - Ran precommit tests for 2 different issues; one of them has passed with the author's fix, the other one hasn't, so I'll probably have to help figure out what the problem is * Set up a BeagleBoard so I can run some tests for TCWG-674 [1/10] == Plan == * [AArch64] Support for label arithmetic in the assembler [TCWG-710] - Send a patch upstream * Run more precommits if necessary

9 years, 8 months

1
0
0 0

[ACTIVITY] Week 33

by Yvan Roux

o one day off (2/10) == Progress == o Linaro GCC/Validation (3/10) - Continuing Backports. - Prepared branch merges - AArch64 builders stable again after Jenkins upgrade. - Investigated GDB build failure with Glibc trunk, Adhemerval patch accepted upstream. - start to merge Bkk16-buildfarm job into main buildfarm one. o Upstream GCC (1/10) - Guality fix: more investigation . o Misc (4/10) * Various meetings and discussions. * Another Internal support. == Plan == o Continue on backports, and FSF branch merge, etc

9 years, 8 months

1
0
0 0

gcc-linaro-6.1-2016.07...Big Endian and Little Endian aarch64 Options

by stimits＠comcast.net

Hi, I was able to get linaro-6.1-2016.07 compiled for both aarch64 and armhf. I also have some prebuilt 5.2 and 5.3 binaries, plus a few other 4.8 and 4.9 compilers from quite some time back. I've used these for building a Linux 3.10 kernel, and the newer linaro-6.1 fails during kernel compile. The issue seems to be the assembler does not recognize option "-EL" (all of the ARM systems I'm building for are little endian, I've not seen a big endian system). I am wondering if support for options "-EB" and "-EL" are part of the configure options? There is the generic "help" listing the "--enable-FEATURE=ARG", but I do not see a comprehensive list of features this might deal with. I'm hoping that big/little endian for armhf and aarch64 can be enabled with this. Otherwise I'm hoping to find more information on what I might need to do or change for compatibility with the "-EL" option. For reference, I have similar templates for 32-bit and 64-bit configuration (different triplet and build root). Here's one: export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export BUILD='/home/build/linaro/32bit'export TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf cd $BUILD${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/ Thanks!

9 years, 8 months

2
1
0 0

gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question

by stimits＠comcast.net

Hi, In a previous thread some sysroot issues were resolved, and I am able to build cross-compilers under gcc-linaro-snapshot-6.1-2016.07 for languages c, c++, and objc. My sysroot consisted of a loopback mounted dd copy of an Ubuntu 14.04 file system for aarch64. That particular file system runs on a quad core Cortex-A57, and is fully capable of compiling many different types of software (the file system is set up for development). The successful configuration was like this (configuration and compile was from an independent directory not in the source tree): export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export TRIPLET=aarch64-linux-gnuexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=arm64 ${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c,c++,objc \ --with-sysroot=/ Now I also need armhf (I must support both 32-bit and 64-bit), so I'm trying to figure out host and sysroot differences (I have been unable to get armhf to compile). The configuration is basically this variation of the above, plus some sysroot additional support: export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf ${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/ Note that for testing purposes I tried to compile only languages of c, c++, and objc, each one at a time instead of together. Errors do not differ in any way for picking of any of those three languages. I also have a complete Ubuntu 14.04 file system for armhf which is fully equipped for building of each of those languages, and is perhaps in some ways more complete as a development environment than the previously successful aarch64 file system (the sysroot runs on a quad core Cortex-A15). I tried this purely armhf file system as the sysroot to rule out incorrect multiarch support, and the error did not change. I am guessing the issue is not the sysroot, but I wanted to verify this since there may be other requirements for armhf instead of aarch64. I am at a loss though to explain why the host would be at issue since it appears all prerequisites were met and I had success with aarch64. The details of the error seem to always occur in libcc1 build. I see this in the libcc1/config.log as the failure regardless of sysroot or supported language, and only while building for armhf: configure:14569: checking for -rdynamicconfigure:14579: result: yesconfigure:14589: checking for library containing dlopenconfigure:14620: gcc -o conftest -g -O2 conftest.c >&5/tmp/ccyhVkpp.o: In function `main':/home/build/linaro/objdir/libcc1/conftest.c:38: undefined reference to `dlopen'collect2: error: ld returned 1 exit statusconfigure:14620: $? = 1configure: failed program was:| /* confdefs.h */| #define PACKAGE_NAME "libcc1"| #define PACKAGE_TARNAME "libcc1"| #define PACKAGE_VERSION "version-unused"| #define PACKAGE_STRING "libcc1 version-unused"| #define PACKAGE_BUGREPORT ""| #define PACKAGE_URL ""| #define STDC_HEADERS 1| #define HAVE_SYS_TYPES_H 1| #define HAVE_SYS_STAT_H 1| #define HAVE_STDLIB_H 1| #define HAVE_STRING_H 1| #define HAVE_MEMORY_H 1| #define HAVE_STRINGS_H 1| #define HAVE_INTTYPES_H 1| #define HAVE_STDINT_H 1| #define HAVE_UNISTD_H 1| #define __EXTENSIONS__ 1| #define _ALL_SOURCE 1| #define _GNU_SOURCE 1| #define _POSIX_PTHREAD_SEMANTICS 1| #define _TANDEM_SOURCE 1| #define HAVE_DLFCN_H 1| #define LT_OBJDIR ".libs/"| #define HAVE_DECL_BASENAME 1| /* end confdefs.h. */ Are there different host requirements when building armhf versus aarch64 which might explain why dlopen is not found? FYI, both development and other support for dlopen exists already on the system, so the failure to find dlopen is not for lack of host support (related dlopen files all seem to be present on all tested sysroots as well, both as armhf and aarch64). Is this a sysroot issue, a host issue, or a configure issue? Thanks!

9 years, 8 months

2
5
0 0

[ACTIVITY] Week 32

by Yvan Roux

== Progress == o Linaro GCC/Validation (3/10) - Backports: tracking missing dependencies. - Looked at our AArch64 builder issues, reproduced the problem. o Upstream GCC (3/10) - Found a fix for guality tests failures, analyzing all the test case which can be impacted. o Misc (4/10) * Various meetings and discussions. * Internal support on GCC == Plan == o Continue on backports, and FSF branch merge o Finalize and submit on-going patches

9 years, 8 months

1
0
0 0

stdc-predef.h failed during gcc-linaro-snapshot-6.1-2016.07 compile

by stimits＠comcast.net

Hi, I've been trying to build the c and c++ cross-compiler for triplet aarch64-linux-gnu (--target=aarch64-linux-gnu --enable-languages=c,c++) on snapshot for 6.1-2016.07, and cannot get past this: cc1: error: no include path in which to search for stdc-predef.h From what I can tell this may already be a known bug inherited from back in the days of Linaro 4.8. I tried various ways around this, such as trying to create an empty stdc-predef.h in various locations, but always ended up either not fixing the issue or breaking something else even sooner. Is there a simple way around this on the configure command line? If not, is there some recommended edit for this? Thanks!

9 years, 8 months

2
3
0 0

[ANNOUNCE] Linaro Binary Toolchain Release-Candidate GCC 6.1-2016.08-rc1

by Ryan Arnold

The Linaro Binary Toolchain ============================ The Linaro GCC 6.1-2016.08-rc1 Release-Candidate is now available. Download release-candidate packages from: http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.08-rc1/ http://snapshots.linaro.org/components/toolchain/binaries/6.1-2016.08-rc1/ Previous snapshots and release-candidates are at: http://snapshots.linaro.org/components/toolchain/binaries/ Previous releases are at: http://releases.linaro.org/components/toolchain/binaries/ Host Requirements ================== Linaro officially supports the current and previous Ubuntu LTS releases (as of the time of this release). This does not mean that the toolchain will not work on other/older Linux distributions. See the following for the life-time of Ubuntu LTS releases. https://wiki.ubuntu.com/Releases The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc's memcpy API. https://bugs.linaro.org/show_bug.cgi?id=1869 Package Versions ================= Linaro GCC 6.1-2016.08-rc1 FSF glibc 2.23 (linaro/2.23) Linaro newlib 2.4.0-2016.03 (linaro-2.4-branch) Linaro binutils 2.26 (linaro_binutils-2_26-branch) FSF GDB 7.11 (binutils-gdb.git~gdb-7.11-branch) Linaro toolchain package git branches are hosted at: http://git.linaro.org/?a=project_list&s=toolchain%2F&btnS=Search NEWS for Linaro GCC 6.1-2016.08-rc1 ==================================== * Performance related backports from Linaro GCC 6.1-2016.06, and Linaro GCC 6.1-2016.07 have been included. See the following Linaro GCC snapshots: http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.06/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.07/ Contact Linaro =============== File bugs at http://bugs.linaro.org For Linaro member support see http://support.linaro.org For Linaro community support email linaro-toolchain(a)lists.linaro.org -- Ryan S. Arnold | Linaro Toolchain Engineering Manager ryan.arnold(a)linaro.org | ryanarn on #linaro-tcwg @ freenode.irc.net

9 years, 8 months

1
0
0 0

[ACTIVITY] 8 - 12 August 2016

by Diana Picus

== Progress == * Refactor SelectionDAGBuilder::visitInlineAsm [TCWG-643] [1/10] - Incorporated some review feedback and committed the patch upstream * [AArch64] Support for label arithmetic in the assembler [TCWG-710] [4/10] - Most of the support seems to be there, but the error checking is too aggressive and it rejects cases that could in fact be handled by the assembler - Trying to figure out exactly what the assembler can currently handle and how to relax the error checking accordingly * [AArch64] Keep merging consecutive stores in store sequences [TCWG-704] [2/10] - Fixing this might slow down the compiler more than the optimization is worth - Got some debug dumps on the test-suite to see how often sequences of consecutive stores show up * Misc [3/10] - Booked trip to Cambridge / Hebden Bridge - Buildbot babysitting (2 nasty selfhost failures), code reviews, LLVM Cauldron == Plan == * [AArch64] Support for label arithmetic in the assembler [TCWG-710] * [AArch64] Keep merging consecutive stores in store sequences [TCWG-704]

9 years, 8 months

1
0
0 0

[ACTIVITY] 8-12 August 2016

by Yao Qi

# Progress # * TCWG-685, GDB 7.12 release. [4/10] Triaged all aarch64 native test results. Two patches fixing heap overflow are posted. The new C++11 ABI tag makes troubles to some gdb.cp tests. Rebuild armhf toolchain for GDB arm native test. glibc failed to build due to "gperf" is not found. * AArch64 OpenOCD investigation. Done. [2/10] Write a report. In general, there was a patch for AArch64 OpenOCD, but some issues should be addressed before it can be merged to mainline. * Interview in US Embassy, and file expense. [2/10] * Misc, meetings, [2/10] # Plan # * TCWG-685, GDB 7.12 release. Build recent native armhf toolchain, and test gdb 7.12 with it. Bug fixes if needed. * Off on Wed and Thu. -- Yao Qi

9 years, 8 months

1
0
0 0

[ACTIVITY] 8-12 August 2016

by Prathamesh Kulkarni

== This Week == * LTO (6/10) a) TCWG-666 (5/10) - Patch iterations based on suggestions from Honza and Martin - Honza approved patch, however I see some failures during bootstrap+test, submitted patch to address those. b) TCWG-548 (1/10) - Benchmarking SPEC2006 on my chromebook cancelled midway due to issues with chromebook. - Setting up hacking session on juno-01 with help from Maxim - Analyzing SPEC2k results. * TCWG-72 (1/10) - Submitted patch upstream to set NULL for sdivmod_optab entry in optabs.def * Bugs (2/10) - Committed fix for fallouts caused by previous patches - TCWG-700: Patch iterations based on upstream discussion * Misc (1/10) - Meetings == Next Week == - Holidays

9 years, 8 months

1
0
0 0

Impact of binutils .align assembler directive parsing bug

by Dan Handley

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.

9 years, 8 months

3
5
0 0

A stable version of gcc-linaro-xxx-arm-linux-gnueabi ...

by darklight wu

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

9 years, 9 months

3
3
0 0

[ACTIVITY] Week 31

by Yvan Roux

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

9 years, 9 months

1
0
0 0

[ACTIVITY] 8 - 12 August 2016

by Prathamesh Kulkarni

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

9 years, 9 months

1
0
0 0

[ACTIVITY] 01-05 Aug 2016

by Yao Qi

# 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

9 years, 9 months

1
0
0 0

[ACTIVITY] 1 - 5 August 2016

by Diana Picus

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

9 years, 9 months

1
0
0 0

[ACTIVITY] 1-5 August 2016

by Christophe Lyon

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

9 years, 9 months

1
0
0 0

[ACTIVITY] 25 - 29 July 2016

by Prathamesh Kulkarni

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

9 years, 9 months

1
0
0 0

vreinterpretq_*_p128 for converting from polynomials?

by Jeffrey Walton

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

9 years, 9 months

2
4
0 0

Compile error when building an Aarch32 program on Aarch64?

by Jeffrey Walton

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.

9 years, 9 months

2
1
0 0

[ACTIVITY] 25-29 July 2016

by Diana Picus

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

9 years, 9 months

1
0
0 0

[ACTIVITY] 25-29 July 2016

by Yao Qi

* Off on Tue and Wed [4/10] # Progress # * TCWG-655, workaround ARM linux kernel ptrace bug on setting VFP registers. Pedro isn't happy about the workaround, and inclined to upgrade kernel. * TCWG-685, GDB 7.12 release. [4/10] Fix a bug on threads are disappeared when gdb detach. GDB gets odd task state (disk sleep) from /proc/<pid>/status, and takes some time understanding what does "disk sleep" mean for a thread to be exited. Patch is being tested. * US visa. [1/10] Get the visa photo, finish the DS-160 form, and make an interview appointment. * Misc, [1/10] # Plan # * TCWG-685, GDB 7.12 release. More testing on aarch32. * TCWG-655. -- Yao

9 years, 9 months

1
0
0 0

[ANNOUNCE] Linaro Binary Toolchain Release GCC 5.3-2016.05

by Ryan Arnold

The Linaro Binary Toolchain ============================ The Linaro GCC 5.3-2016.05 Release is now available. Notice: All Linaro GCC 5 series toolchain users should migrate to the latest version of the Linaro GCC 5 toolchain in order to mitigate potential security exposure to CVE-2015-7547. See the NEWS section below for details. Download release packages from: http://releases.linaro.org/components/toolchain/gcc-linaro/5.3-2016.05/ http://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/ Previous snapshots and release-candidates are at: http://snapshots.linaro.org/components/toolchain/binaries/ Previous releases are at: http://releases.linaro.org/components/toolchain/binaries/ Host Requirements ================== Linaro officially supports the current and previous Ubuntu LTS releases (as of the time of this release). This does not mean that the toolchain will not work on other/older Linux distributions. See the following for the life-time of Ubuntu LTS releases. https://wiki.ubuntu.com/Releases The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc's memcpy API. https://bugs.linaro.org/show_bug.cgi?id=1869 Package Versions ================= Linaro GCC 5.3-2016.05 Linaro glibc 2.21 (linaro/2.21) Linaro newlib 2.1.0-2014.09 (linaro_newlib-branch) Linaro binutils 2.25 (linaro_binutils-2_25-branch) FSF GDB 7.10 (gdb-7.10-branch) Linaro toolchain package git branches are hosted at: http://git.linaro.org/?a=project_list&s=toolchain%2F&btnS=Search NEWS for Linaro GCC 5.3-2016.05 ================================ * Increment binutils release date to 2016_02 to reflect the most recent commit: commit ef90a4718f535cbe6345b4e7168baea7b1972abf Author: Matthew Wahab <matthew.wahab(a)arm.com> Date: Tue Jan 12 16:35:30 2016 +0000 [ARM] Support ARMv8.2 RAS extension. * Baremetal sysroot names now contain 'newlib' rather than 'glibc'. * Manifests now contain relative paths rather than absolute paths. * Now generating proper manifest files. * Fixed pi requeue support in glibc 2.21 while allowing the existing 2.21 minimum kernel default setting. This was checked into the linaro/2.21/master branch. commit a68cafa11c500d8a49a3014c43c5152859d037ae Author: Adhemerval Zanella <adhemerval.zanella(a)linaro.org> Date: Tue May 17 10:16:39 2016 -0300 Add runtime check for __ASSUME_REQUEUE_PI (BZ# 18463) commit 6e5cb616b5b442ce8b2664ad673c0acf42a490ac Author: Adhemerval Zanella <adhemerval.zanella(a)linaro.org> Date: Mon May 16 19:01:10 2016 -0300 Remove __ASSUME_SET_ROBUST_LIST commit 9ac61c0047295696cbcdbc26bdc174c7bd25a3c8 Author: Adhemerval Zanella <adhemerval.zanella(a)linaro.org> Date: Mon May 16 10:35:25 2016 -0300 Remove __ASSUME_FUTEX_LOCK_PI * Backported support into GCC for Cortex-A32, Cortex-A35, and Cortex-R8. * Applied fix for CVE-2015-7547 - A stack-based buffer overflow in glibc's getaddrinfo() was corrected in glibc 2.23 and backported into glibc 2.21. https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html * ARMv8.1 Instruction Support - ARMv8.1 instructions support was checked into GCC and binutils. It has been backported into Linaro GCC 5.3 and Linaro binutils 2.25. * Backported -Bsymbolic-functions into Linaro binutils 2.25. * Performance related backports from Linaro GCC 5.2-2015.11, Linaro GCC 5.2-2015.12, and Linaro GCC 5.3-2016.01-1, Linaro GCC 5.3-2016.02, Linaro GCC 5.3-2016.03, and Linaro GCC 5.3-2016.04 have been included. See the following Linaro GCC snapshots: http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.2-2015.11/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2015.12/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2016.01-1/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2016.02 http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2016.03 http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2016.04 Contact Linaro =============== File bugs at http://bugs.linaro.org For Linaro member support see http://support.linaro.org For Linaro community support email linaro-toolchain(a)lists.linaro.org -- Ryan S. Arnold | Linaro Toolchain Engineering Manager ryan.arnold(a)linaro.org | ryanarn on #linaro-tcwg @ freenode.irc.net T: +1-612-424-1861 <+16124241861>

9 years, 9 months

1
0
0 0

[ACTIVITY] 18-22 July 2016

by kugan

== Progress == * IPA VRP and Early VRP - Posted patch series and revised based on review - Few patches are accepted; others are waiting for re-review * Tree VRP - Converted to use allocpool * Committed upstream tree-reassoc patch for missed optimization due to factoring out CONVERT_EXPR in phiopt. == Plan == - Follow upon remaining upstream patches - IPA VRP

9 years, 9 months

1
0
0 0

[ACTIVITY] 18 - 22 July 2016

by Prathamesh Kulkarni

== This Week == * TCWG-666 (2/10) - Working through bootstrap and regtest failures * TCWG-548 (1/10) - Running benchmarks on chromebook (cortex-a15) * Bugs (5/10) - PR71947: Richard committed fix in vrp which solves this at -O2. - PR70920: Patch passes bootstrap+test. - Wrote patch to make ipa-pure-const pass warn for unused return values - PR71315: Verified works on trunk, exposed another bug in tree-ssa-strlen * Misc (2/10) - Recovery from sprint == Next Week == - Continue with TCWG-666 and TCWG-548 - Bugs

9 years, 9 months

1
0
0 0

[ACTIVITY] 18-22 July 2016

by Yao Qi

# Progress # * TCWG-518, ARM range stepping patches. [2/10] The last one is approved, and all patches are committed! Need to enable range stepping and collect the performance data. Range stepping should speed up remote debugging. * TCWG-655, Workaround ARM linux kernel ptrace bug on setting VFP registers. No response from upstreams. * TCWG-333, Thumb mode function pointer assignment in GDB. [3/10] Try a different approach, still causes regressions. I'll ask upstream how to do it. * TCWG-547, Change software_single_step interface to return a vector of address. [4/10]. Patches are done, but need to figure out how to hook them together. * TCWG-685, GDB 7.12 release. [1/10] The release will be in Sep, and hopefully it can be done before the Linaro Connect. Discuss on how/when to pick up 7.12 in Linaro toolchain release. I am inclined to upgrade GDB in linaro release from 7.11 to 7.12 in fall or winter. # Plan # * Off on Tue and Wed. * GDB 7.12 release testing for ARM and AArch64. * US visa application. -- Yao

9 years, 9 months

1
0
0 0

[ACTIVITY] 18-22 July 2016

by Peter Smith

== Progress == TCWG-680 Some analysis on what non-compiler support would be required for an llvm based EBC (UEFI) toolchain. TCWG-612 ARM TLS support in LLD: Initial support and tests for standard model upstreamed. There is still some work to be done for corner cases where LLD's relaxations will cause assertion failures. Static linking also needs some work as the TLS module index needs to be written into the GOT without a dynamic relocation. I have a prototype fix that needs cleaning up and tests written. Did some experiments with static linking and TLS to work out what I'll need to look at next. Discovered GNU ifunc support when static linking is not working. Did some thinking about what would be needed to support C++ exceptions in LLD for ARM. This is probably the next major chunk of work as supporting exceptions is needed when static linking against the C library startup code. == Plans == Plans for next 4 weeks: On Sabbatical back on the 22nd August. Will probably have limited access to email if there is anything urgent. Peter

9 years, 9 months

1
0
0 0

[ACTIVITY] 18-22 July 2016

by Diana Picus

== Progress == * ARM: Different ABI functions based on optimization level [TCWG-669] - Patch committed upstream * PR26038 - inline assembly assertion building ARM linux kernel [TCWG-590] [2/10] - Patch committed upstream * PR24234 - [AArch64] error in backend: fixup value out of range [TCWG-681] [5/10] - Started investigating * AArch64 Bugzilla scrub [2/10] - Closed a couple of bugs that couldn't be reproduced - Added a few interesting bugs to TCWG-678 * Minor updates to the helper scripts [TCWG-630, TCWG-649] [1/10] == Plan == * PR24234 - [AArch64] error in backend: fixup value out of range [TCWG-681] - Looks like a tough one :)

9 years, 9 months

1
0
0 0

What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

by Jeffrey Walton

Hi Everyone, I'm looking at the features of a BeagleBone Black. Its /proc/cpuinfo is below. I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags neon and vfpv3 flags means I want something more than -mfpu=neon-fp16, but I'm not sure what that is. My question is, what GCC ARM option is used when we encounter the neon, vfpv3 and vfpd32 flags? Thanks in advance. ********** $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 2 (v7l) BogoMIPS : 996.14 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : Generic AM33XX (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000

9 years, 9 months

3
7
0 0

-mfpu=neon-fp-armv8 and unrecognized command line option

by Jeffrey Walton

Hi Everyone, I'm having trouble with ARMv8/Aarch64. One is an early Mustang server board (without CRC or Crypto), and the other is a LeMaker HiKey (with CRC and Crypto). Both run Linaro: apm-mustang: $ cat /proc/cpuinfo Features : fp asimd evtstrm And: hikey: $ cat /proc/cpuinfo Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 According to the GCC folks, we can get better code generation with -mfpu=neon-fp-armv8 (http://gcc.gnu.org/ml/gcc-help/2016-05/msg00058.html and https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html). However, it results in: $ g++ -DDEBUG -g3 -O0 -mfpu=neon-fp-armv8 -fPIC -pipe -c cryptlib.cpp g++: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’ GNUmakefile:753: recipe for target 'cryptlib.o' failed It looks like -mfpu=neon-fp-armv8 is a GCC 4.9 feature (http://gcc.gnu.org/gcc-4.9/changes.html), and Linaro supplies GCC 4.9.2: $ g++ --version g++ (Debian/Linaro 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. I'm wonder why the option is not being consumed by GCC. Are there any ideas what I should be doing differently? Thanks in advance. Jeff

9 years, 9 months

3
5
0 0

[ACTIVITY] 4-15 July 2016

by Yao Qi

* On holiday [6/20] # Progress # * TCWG-655, Workaround ARM linux kernel ptrace bug. [2/20] After the discussion, patch is posted. Pedro is on holiday, so the patch is pending there for review. * TCWG-518, ARM range stepping patches. [3/20] The last "to-be-approved" patch is posted. Pending for review. * TCWG-333, Thumb mode function pointer assignment in GDB. [2/20] Working on a patch to handle both ARM/thumb and PPC64. * TCWG-179, TLS variables can't be resolved in aarch64 GDB. [4/20] GCC doesn't produce DW_AT_location for TLS variable, because target hook TARGET_ASM_OUTPUT_DWARF_DTPREL isn't defined for AArch64. Thanks to Jiong and Szabolcs's help, pick up knowledge on TLS descriptor and TLS modes quickly. Still need to figure out how to describe the location of TLS variable in debug info if they are unknown in compilation/link time. * Fix gdb.gdb/*.exp and gdb.mi/mi-reverse.exp test fails. [1/20] * Upstreams patch review. [1/20] * LAS16, sort out the invitation letter for US visa. [1/20] # Plan # * TCWG-333, TCWG-518, TCWG-655 and TCWG-179 * US visa application. -- Yao

9 years, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain