[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) {
$
The Linaro Toolchain Working Group (TCWG) is pleased to announce the
2017.01 snapshot of the Linaro GCC 6 source package.
This monthly snapshot[1] is based on FSF GCC 6.3+svn244220 and
includes performance improvements and bug fixes backported from
mainline GCC. This snapshot contents will be part of the 2017.02
stable[2] quarterly release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.3-2017.01/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 6.3+svn244220
* Backport of [Bugfix] Fix PR77673: bswap loads passed end of object
* Backport of [ARMv8-M] [AArch32] 1/7 Move memory model declarations
in memmodel.h
* Backport of [ARMv8-M] [AArch32] 2/7 Adapt atomic and exclusive load
and store to ARMv8-M Baseline
* Backport of [ARMv8-M] [AArch32] 3/7 Refactor atomic compare_and_swap
to make it fit for ARMv8-M Baseline
* Backport of [ARMv8-M] [AArch32] 4/7 Adapt atomic compare and swap to
ARMv8-M Baseline
* Backport of [ARMv8-M] [AArch32] 5/7 Adapt other atomic operations to
ARMv8-M Baseline
* Backport of [ARMv8-M] [AArch32] 7/7 Enable ARMv8-M atomic and
synchronization support for ARMv8-M Baseline
* Backport of [ARMv8-M] [AArch32] Added support for ARMV8-M Security
Extension cmse_nonsecure_caller intrinsic
* Backport of [ARMv8-M] [AArch32] Add multilib mapping for Cortex-M23
& Cortex-M33
* Backport of [ARMv8-M] [AArch32] Add support for ARM Cortex-M23 processor
* Backport of [ARMv8-M] [AArch32] Add support for ARM Cortex-M33 processor
* Backport of [ARMv8-M] [AArch32] Add support for ARMv8-M's Secure
Extensions flag and intrinsics
* Backport of [ARMv8-M] [AArch32] ARMv8-M Security Extension's
cmse_nonsecure_call: use __gnu_cmse_nonsecure_call
* Backport of [ARMv8-M] [AArch32] ARMv8-M Security Extension's
cmse_nonsecure_entry: __acle_se label and bxns return
* Backport of [ARMv8-M] [AArch32] ARMv8-M Security Extension's
cmse_nonsecure_entry: clear registers
* Backport of [ARMv8-M] [AArch32] Fix various arm failures with config-list.mk
* Backport of [ARMv8-M] [AArch32] Force soft float in ARMv6-M and
ARMv8-M Baseline options
* Backport of [ARMv8-M] [AArch32] Handling ARMv8-M Security
Extension's cmse_nonsecure_call attribute
* Backport of [ARMv8-M] [AArch32] Handling ARMv8-M Security
Extension's cmse_nonsecure_entry attribute
* Backport of [ARMv8-M] [AArch32] Make arm_feature_set agree with type
of FL_* macros
* Backport of [ARMv8-M] [AArch32] Optional -mthumb for Thumb only targets
* Backport of [AArch64] 1/3 Add missing Poly64_t intrinsics to GCC
* Backport of [AArch64] 2/3 Add missing Poly64_t intrinsics to GCC
* Backport of [AArch64] 3/3 Add tests for missing Poly64_t intrinsics to GCC
* Backport of [AArch64] Add more Poly64_t intrinsics to GCC
* Backport of [AArch64] more poly64 intrinsics
* Backport of [Testsuite] [AArch64] Fix failing poly64 tests on ARM
* Backport of [Testsuite] [AArch64] Lower iterator count on
gcc.dg/atomic/c11-atomic-exec-5.c for AARCH64
* Backport of [Cleanup] Improve comment for struct symbolic_number in bswap pass
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.
o 1 day off (2/10)
o Teaching activity (4/10)
== Progress ==
o Linaro GCC/Validation (2/10)
* 5.4-2017.01-rc1 release notes and publication
* Some infra bugfixes and reviews
o Misc (1/10)
* Various meetings and discussions.
* Plan for 2017
== Plan ==
o GCC 6 branch merge and snapshot
