=== This Week ===
Monitor LLDB buildbot for minimum down time. [TCWG-712] [1/10]
-- LLDB Arm build was broken and then fixed upstream but a buildbot script bug.
-- Fixed buildbot script to make sure not every type of build is
refreshed after a breakage.
Investigate LLDB testsuite failures on Pine64 target (AArch32 and
AArch64 modes) [TCWG-1012] [3/10]
-- Investigated and fixed TestRegisterVariables
(https://reviews.llvm.org/D28666)
-- Fixed a log issue which I initially thought was a bug.
(https://reviews.llvm.org/rL291889)
-- No further AArch64 failures except for one test timedout needs
further investigation.
-- Some tests fail randomly on AArch32 but pass when run individually.
More investigation needed.
LLDB Arm/AArch64 Investigate and fix testsuite crashes (Pine64
Crashes) [TCWG-792] [2/10]
-- There was some problem occuring when multiple versions of python
are installed on tester.
-- Also some tests are leaving behind runaway processes.
-- Cleaned up testers removed python issue ended up reducing test time
to 3 minutes.
-- Trying to track runaway processes.
Miscellaneous Activities [4/10]
-- Travel to Islamabad for Hungary visa interview (9th-10th Jan 2017).
-- Meetings, Emails etc.
=== Next Week ===
ARM/AArch64 hardware breakpoints [TCWG-717]
-- Investigate current status and create task breakdown.
Investigate LLDB testsuite failures on Pine64 target (AArch32 and
AArch64 modes) [TCWG-1012]
-- Further tracking on runaway processes when running AArch32 testsuite.
-- Investigation of timedout tests on AArch64.
o Teaching activity (4/10)
== Progress ==
o Linaro GCC/Validation (4/10)
* Merge FSF GCC 6 branch into Linaro one
* Backports reviews
* Delivered snapshot of 6.3-2017.01 source package
* Merge FSF 4.9 branch into Linaro one
o Misc (2/10)
* Various meetings and discussions.
== Plan ==
o Last GCC 4.9 snapshot
o GCC 5.4 release
[TCWG-614] Long branch thunks:
Implemented a prototype of the existing Thunk implementation using
Synthetic (Linker created sections) and moved it close to the area it
will need to go for Long Branch Thunk work.
Worked on this exclusively all week.
Plans for next week:
[TCWG-614] Long branch thunks:
Tidy up and refactor prototype to a point where I can post for
upstream review. This won't be long-branch thunk support but it will
be a significant intermediate step.
Do a draft plan of Connect submission and decide how long I need.
== Progress ==
* [ARM] Use AddDefaultPred everywhere [TCWG-987] [1/10]
- Proposed a refactoring first [TCWG-1015]
- Rebased initial patch after the refactoring, still waiting for review
* Refactor AddDefaultPred [TCWG-1015] [4/10]
- Initial implementation was a bit heavyweight, so I worked on a
simpler version based on people's suggestions
- Committed upstream
* Misc [5/10]
- Got up to speed after vacation
- Booked travel for Connect and EuroLLVM
- FOSDEM slides
- Upstream code reviews
- Reverted and ran pre-commit tests for some compiler-rt patches
that broke the buildbots
== Plan ==
* 3 days off (Mon-Wed)
* [ARM GlobalISel] Add support for integers < 32 bits wide [TCWG-980]
- I have 3 patches in upstream review, I will keep pinging them
- Putting GlobalISel work on hold until these patches go through
~ Progress ~
* TCWG-984 Handle exception/error in disassembly, [4/10]
Patches are posted and reviewed. Three patches to opcodes
are approved and committed. V2 is done to address comments
on C++ and unit tests. V2 are being tested.
* Patches review, [4/10]
** Review some preparatory SVE patches from Alan.
They are good to me, but I expect Joel or someone else to take a look
as well.
** Linux kernel awareness debugging.
Review the patch sent from linaro, but some one from IBM sends
a similar patch series. These two patch sets look similar, but are
different on some parts.
* Conversation with Paul (openocd maintainer) on irc. [1/10]
They really want me to look at some gdb+openocd issues. My Hikey
will arrive soon, but they give me some explanations on why cortex-m
board is better than cortex-a board in bare-metal, because of
simplicity. I explained to them why Linaro focused on cortex-a
devices so far.
* Linaro Connect. [1/10]
Register the connect, book flight and hotel.
~ Plan ~
* TCWG-984 and TCWG-333
* Carefully read Dave M's SVE user space VL control API.
* Carefully read IBM's kernel debugging patches.
--
Yao Qi
== This Week ==
* TCWG-1005 (malloc attr propagation) (6/10)
- Worked through bootstrap failures
- Patch found 35 functions that could have malloc attribute during gcc build
- The current analysis to find candidate functions is too restrictive, working
on improving that.
- Wrote few test-cases.
* TCWG-1006 (returns_nonnull attr propagation) (2/10)
- WIP prototype patch
* TCWG-1010 (bitwise-dce) (1/10)
- Going thru demanded-bits analysis
* Misc (1/10)
- Meetings
== Next Week ==
- Continue working on TCWG-1005, TCWG-1006 and TCWG-1010
== Progress ==
* Validation
- improvements and bug fixes:
ABE #2764. and make_docs problem for gcc-4.9 builds)
Enhanced abe validation to check builds of
gcc-4.9, 5 and 6.
make-and-test-release now works.
buildbench now works
* GCC
- Committed fix for pr78253
- discussions on releases (packaging, process improvements)
- a few backports for our 6.2-2017.01 snapshot
* misc (conf-calls, meetings, emails, ....)
- bugzilla followup
- moving from ex40-01 to dev-01
- Connect registration: on-going
== Next ==
* ABE & Jenkins jobs patches reviews and bug fixes
* GCC:
- bug fixing
Thanks guys, that was it.
I did not realize the build system was omitting the flags.
On Fri, Jan 13, 2017 at 2:23 AM, Pinski, Andrew
<Andrew.Pinski(a)cavium.com> wrote:
> Can you try -march=armv8+crypto ?
>
> -----Original Message-----
> From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Jeffrey Walton
> Sent: Thursday, January 12, 2017 10:56 PM
> To: Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>
> Subject: Does Linaro's GCC 4.9 include Crypto extensions and intrinsics?
>
> Please forgive my ignorance. I'm working on a Pine64 dev-board Pine64 supplies Linaro's GCC 4.9.2 toolchain.
>
> I am catching a compile error, and I am trying to determine why.
>
> Does Linaro's GCC 4.9 provide AES and SHA intrinsics?
Please forgive my ignorance. I'm working on a Pine64 dev-board Pine64
supplies Linaro's GCC 4.9.2 toolchain.
I am catching a compile error, and I am trying to determine why.
Does Linaro's GCC 4.9 provide AES and SHA intrinsics?
**********
$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16
10:53:13 CEST 2016 aarch64 GNU/Linux
$ gcc --version
gcc (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
**********
$ CFLAGS="-DMBEDTLS_HAVE_ARMV8A_CE=1" make DEBUG=1 V=1
CC aes_armv8a_ce.c
aes_armv8a_ce.c: In function 'mbedtls_armv8a_ce_aes_crypt_ecb':
aes_armv8a_ce.c:65:4: warning: implicit declaration of function
'vaeseq_u8' [-Wimplicit-function-declaration]
state_vec = vaeseq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:65:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaeseq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:67:4: warning: implicit declaration of function
'vaesmcq_u8' [-Wimplicit-function-declaration]
state_vec = vaesmcq_u8( state_vec );
^
aes_armv8a_ce.c:67:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesmcq_u8( state_vec );
^
aes_armv8a_ce.c:74:13: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaeseq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:84:4: warning: implicit declaration of function
'vaesdq_u8' [-Wimplicit-function-declaration]
state_vec = vaesdq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:84:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesdq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:86:4: warning: implicit declaration of function
'vaesimcq_u8' [-Wimplicit-function-declaration]
state_vec = vaesimcq_u8( state_vec );
^
aes_armv8a_ce.c:86:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesimcq_u8( state_vec );
^
aes_armv8a_ce.c:93:13: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesdq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c: In function 'mbedtls_armv8a_ce_gcm_mult':
aes_armv8a_ce.c:138:2: warning: implicit declaration of function
'vmull_high_p64' [-Wimplicit-function-declaration]
r1 = (uint8x16_t)vmull_high_p64( (poly64x2_t)a_p, (poly64x2_t)b_p );
^
aes_armv8a_ce.c:138:2: error: can't convert between vector values of
different size
aes_armv8a_ce.c:141:2: error: can't convert between vector values of
different size
t0 = (uint8x16_t)vmull_high_p64( (poly64x2_t)a_p, (poly64x2_t)t0 );
^
aes_armv8a_ce.c:150:2: error: can't convert between vector values of
different size
t0 = (uint8x16_t)vmull_high_p64( (poly64x2_t)r1, (poly64x2_t)p );
^
Makefile:170: recipe for target 'aes_armv8a_ce.o' failed
make[1]: *** [aes_armv8a_ce.o] Error 1
Makefile:17: recipe for target 'lib' failed
make: *** [lib] Error 2
**********
CC sha1_armv8a_ce.c
sha1_armv8a_ce.c: In function 'mbedtls_armv8a_ce_sha1_process':
sha1_armv8a_ce.c:99:2: warning: implicit declaration of function
'vsha1h_u32' [-Wimplicit-function-declaration]
e1 = vsha1h_u32( a );
^
sha1_armv8a_ce.c:100:2: warning: implicit declaration of function
'vsha1cq_u32' [-Wimplicit-function-declaration]
abcd = vsha1cq_u32( abcd, e, wk0 ); /* 0 */
^
sha1_armv8a_ce.c:100:7: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
abcd = vsha1cq_u32( abcd, e, wk0 ); /* 0 */
^
sha1_armv8a_ce.c:102:2: warning: implicit declaration of function
'vsha1su0q_u32' [-Wimplicit-function-declaration]
w0 = vsha1su0q_u32( w0, w1, w2 );
^
sha1_armv8a_ce.c:102:5: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
w0 = vsha1su0q_u32( w0, w1, w2 );
^
sha1_armv8a_ce.c:106:7: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
abcd = vsha1cq_u32( abcd, e1, wk1 ); /* 1 */
^
sha1_armv8a_ce.c:108:2: warning: implicit declaration of function
'vsha1su1q_u32' [-Wimplicit-function-declaration]
w0 = vsha1su1q_u32( w0, w3 );
^
sha1_armv8a_ce.c:108:5: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
w0 = vsha1su1q_u32( w0, w3 );
^
sha1_armv8a_ce.c:109:5: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
w1 = vsha1su0q_u32( w1, w2, w3 );
^
...
**********
$ grep -IR vaeseq_u8 /usr/include
/usr/include/clang/3.5.0/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
/usr/include/clang/3.5.0/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
/usr/include/clang/3.5/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
/usr/include/clang/3.5/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
$