linaro-toolchain September 2016

linaro-toolchain@lists.linaro.org

15 participants
27 discussions

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!

7 years, 7 months

[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

7 years, 8 months

[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

7 years, 8 months

[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

7 years, 8 months

[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

7 years, 8 months

[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

7 years, 8 months

[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.

7 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain September 2016