Re: GNU GCC development plan and its interaction with Linaro
Thanks Yvan Roux & Charles Baylis for the help. On 2 December 2015 at 20:20, Charles Baylis wrote: > On 2 December 2015 at 14:15, Yvan Roux wrote: > > >> 1. What is the difference between experimental(gcc 6.0.0 stage 3) & gcc > >> release branch (gcc 5.2.1)? > > > > trunk (actual gcc 6.0.0) is where everything goes, new features, new > > optimizations, new targets, bugfixes, etc ... On release branches it > > is mainly bugfixes even if maintainers can do some exception sometimes > > > >> Is there any rule which decides which changes will go where? > >> In case, I have some patches for new aarch64 processor at present, > in > >> which branch these changes would be merged (assuming they passes > reviews)? > > > > in trunk, but only in stage 1, if you submit it today, it will be in GCC > 7.0.0 > > IIRC, in some circumstances such patches can be acceptable during > Stage 3 if they are sufficiently self-contained and the port > maintainer accepts them. > -- with regards, Virendra Kumar Pathak ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
incomplete .arch specifiers with latest Linaro gcc5 patches on armv8?
Hi,
when working with the Linaro patches I found that a particular commit
breaks our aarch64 kernel build.
The patch in question is that one:
commit be09330da9d0777c4a58568d137e3f8a3dbe0a0b
Author: Yvan Roux
Date: Tue Oct 27 21:18:19 2015 +0100
One of the things it attempts to change apparently is moving the .arch
specifiers in the assembler file from a global scope to individual
functions. What also happens though is that they seem to lose some
information after that transformation.
I observed that when building arch/arm64/crypto/aes-ce-cipher.c from
the Linux kernel. This code contains inline assembly like this:
static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
{
struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
struct aes_block *out = (struct aes_block *)dst;
struct aes_block const *in = (struct aes_block *)src;
void *dummy0;
int dummy1;
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
" ld1 {v1.2d}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
" ld1 {v3.2d}, [%[key]], #16 ;"
"1: aesdv0.16b, v2.16b ;"
" aesimc v0.16b, v0.16b ;"
"2: ld1 {v1.2d}, [%[key]], #16 ;"
" aesdv0.16b, v3.16b ;"
" aesimc v0.16b, v0.16b ;"
"3: ld1 {v2.2d}, [%[key]], #16 ;"
" subs%w[rounds], %w[rounds], #3 ;"
" aesdv0.16b, v1.16b ;"
" aesimc v0.16b, v0.16b ;"
" ld1 {v3.2d}, [%[key]], #16 ;"
" bpl 1b ;"
" aesdv0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
" st1 {v0.16b}, %[out];"
: [out] "=Q"(*out),
[key] "=r"(dummy0),
[rounds]"=r"(dummy1)
: [in]"Q"(*in),
"1"(ctx->key_dec),
"2"(num_rounds(ctx) - 2)
: "cc");
kernel_neon_end();
}
Now without this patch the compiler behaved like the following. It was
invoked with:
aarch64-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.aes-ce-cipher.o.d
-nostdinc -isystem
/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/bin/../lib/gcc/aarch64-linux-gnu/5.2.1/include
-I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/include
-Iarch/arm64/include/generated/uapi -Iarch/arm64/include/generated
-I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include
-Iinclude
-I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/include/uapi
-Iarch/arm64/include/generated/uapi
-I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include/uapi
-Iinclude/generated/uapi -include
/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include/linux/kconfig.h
-I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/crypto
-Iarch/arm64/crypto -D__KERNEL__ -mlittle-endian -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89
-mgeneral-regs-only -fno-delete-null-pointer-checks -O2
--param=allow-store-data-races=0 -Wframe-larger-than=2048
-fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -g -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack
-Werror=implicit-int -Werror=strict-prototypes -Werror=date-time
-DCC_HAVE_ASM_GOTO -Werror -march=armv8-a+crypto
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(aes_ce_cipher)"
-D"KBUILD_MODNAME=KBUILD_STR(aes_ce_cipher)" -c -o
arch/arm64/crypto/aes-ce-cipher.o
/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/crypto/aes-ce-cipher.c
As a result it created a file for the assembler with the global
.arch armv8-a+fp+simd+crypto
at the beginning of the file.
After the patch it create
[ACTIVITY] Nov 30- Dec 4, 2015
== Progress == * Validation - a few cleanup patches in the comparison scripts - contribute to debug of ptys allocation problems: the tests pass when executed outside of our schroots. - improvements in the reports from the validation done in the ST Compute Farm - reported a few regressions * GCC - cleanup patch for target attributes tests, - pr68620 (fp16 transfers in big-endian mode) * Misc (conf calls, meetings, emails, ) == Next == * Validation: monitoring, improvements * GCC: bug fixes, cleanup ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: incomplete .arch specifiers with latest Linaro gcc5 patches on armv8?
Hi Robert,
On 4 December 2015 at 15:13, Robert Schiele wrote:
> Hi,
>
> when working with the Linaro patches I found that a particular commit
> breaks our aarch64 kernel build.
>
> The patch in question is that one:
>
> commit be09330da9d0777c4a58568d137e3f8a3dbe0a0b
> Author: Yvan Roux
> Date: Tue Oct 27 21:18:19 2015 +0100
>
> One of the things it attempts to change apparently is moving the .arch
> specifiers in the assembler file from a global scope to individual
> functions. What also happens though is that they seem to lose some
> information after that transformation.
>
> I observed that when building arch/arm64/crypto/aes-ce-cipher.c from
> the Linux kernel. This code contains inline assembly like this:
>
> static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const
> src[])
> {
> struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
> struct aes_block *out = (struct aes_block *)dst;
> struct aes_block const *in = (struct aes_block *)src;
> void *dummy0;
> int dummy1;
>
> kernel_neon_begin_partial(4);
>
> __asm__(" ld1 {v0.16b}, %[in] ;"
> " ld1 {v1.2d}, [%[key]], #16 ;"
> " cmp %w[rounds], #10 ;"
> " bmi 0f ;"
> " bne 3f ;"
> " mov v3.16b, v1.16b ;"
> " b 2f ;"
> "0: mov v2.16b, v1.16b ;"
> " ld1 {v3.2d}, [%[key]], #16 ;"
> "1: aesdv0.16b, v2.16b ;"
> " aesimc v0.16b, v0.16b ;"
> "2: ld1 {v1.2d}, [%[key]], #16 ;"
> " aesdv0.16b, v3.16b ;"
> " aesimc v0.16b, v0.16b ;"
> "3: ld1 {v2.2d}, [%[key]], #16 ;"
> " subs%w[rounds], %w[rounds], #3 ;"
> " aesdv0.16b, v1.16b ;"
> " aesimc v0.16b, v0.16b ;"
> " ld1 {v3.2d}, [%[key]], #16 ;"
> " bpl 1b ;"
> " aesdv0.16b, v2.16b ;"
> " eor v0.16b, v0.16b, v3.16b ;"
> " st1 {v0.16b}, %[out];"
>
> : [out] "=Q"(*out),
> [key] "=r"(dummy0),
> [rounds]"=r"(dummy1)
> : [in]"Q"(*in),
> "1"(ctx->key_dec),
> "2"(num_rounds(ctx) - 2)
> : "cc");
>
> kernel_neon_end();
> }
>
> Now without this patch the compiler behaved like the following. It was
> invoked with:
>
> aarch64-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.aes-ce-cipher.o.d
> -nostdinc -isystem
> /var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/bin/../lib/gcc/aarch64-linux-gnu/5.2.1/include
> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/include
> -Iarch/arm64/include/generated/uapi -Iarch/arm64/include/generated
> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include
> -Iinclude
> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/include/uapi
> -Iarch/arm64/include/generated/uapi
> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include/uapi
> -Iinclude/generated/uapi -include
> /var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include/linux/kconfig.h
>
> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/crypto
> -Iarch/arm64/crypto -D__KERNEL__ -mlittle-endian -Wall -Wundef
> -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
> -Werror-implicit-function-declaration -Wno-format-security -std=gnu89
> -mgeneral-regs-only -fno-delete-null-pointer-checks -O2
> --param=allow-store-data-races=0 -Wframe-larger-than=2048
> -fno-stack-protector -Wno-unused-but-set-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls
> -fno-var-tracking-assignments -g -Wdeclaration-after-statement
> -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
> -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time
> -DCC_HAVE_ASM_GOTO -Werror -march=armv8-a+crypto
> -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(aes_ce_cipher)"
> -D"KBUILD_MODNAME=KBUILD_STR(aes_ce_cipher)" -c -o
> arch/arm64/crypto/aes-ce-cipher.o
> /var/fpwork/rschiele/c
[ACTIVITY] 30th Nov - 04th Dec
* One day off on Monday. # Progress # * Answer ST questions about supporting multi-arch with ST jtag probe. [1/10] * TCWG-171, Enable gdb core file tests when testing remotely, [3/10]. Ongoing. * Run gdb.base/sizeof.exp with board having gdb,noinferiorio. Done. [1/10] * TCWG-460, mutli-arch follow-up work, teach AArch64 GDBserver understand ARM breakpoint instructions. Patch is approved. [2/10]. * TCWG-424, fail in gdb.base/random-signal.exp. [1/10] Root cause is identified, need to figure out how to fix it in next step. * Review ARM GDBserver software single step patch V4. # Plan # * TCWG-171, TCWG-156, TCWG-424. * Review ARM GDBserver software single step patch V5, which should be the final version, I hope. -- Yao ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: incomplete .arch specifiers with latest Linaro gcc5 patches on armv8?
On 4 December 2015 at 16:47, Yvan Roux wrote:
> Hi Robert,
>
>
>
> On 4 December 2015 at 15:13, Robert Schiele wrote:
>> Hi,
>>
>> when working with the Linaro patches I found that a particular commit
>> breaks our aarch64 kernel build.
>>
>> The patch in question is that one:
>>
>> commit be09330da9d0777c4a58568d137e3f8a3dbe0a0b
>> Author: Yvan Roux
>> Date: Tue Oct 27 21:18:19 2015 +0100
>>
>> One of the things it attempts to change apparently is moving the .arch
>> specifiers in the assembler file from a global scope to individual
>> functions. What also happens though is that they seem to lose some
>> information after that transformation.
>>
>> I observed that when building arch/arm64/crypto/aes-ce-cipher.c from
>> the Linux kernel. This code contains inline assembly like this:
>>
>> static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const
>> src[])
>> {
>> struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
>> struct aes_block *out = (struct aes_block *)dst;
>> struct aes_block const *in = (struct aes_block *)src;
>> void *dummy0;
>> int dummy1;
>>
>> kernel_neon_begin_partial(4);
>>
>> __asm__(" ld1 {v0.16b}, %[in] ;"
>> " ld1 {v1.2d}, [%[key]], #16 ;"
>> " cmp %w[rounds], #10 ;"
>> " bmi 0f ;"
>> " bne 3f ;"
>> " mov v3.16b, v1.16b ;"
>> " b 2f ;"
>> "0: mov v2.16b, v1.16b ;"
>> " ld1 {v3.2d}, [%[key]], #16 ;"
>> "1: aesdv0.16b, v2.16b ;"
>> " aesimc v0.16b, v0.16b ;"
>> "2: ld1 {v1.2d}, [%[key]], #16 ;"
>> " aesdv0.16b, v3.16b ;"
>> " aesimc v0.16b, v0.16b ;"
>> "3: ld1 {v2.2d}, [%[key]], #16 ;"
>> " subs%w[rounds], %w[rounds], #3 ;"
>> " aesdv0.16b, v1.16b ;"
>> " aesimc v0.16b, v0.16b ;"
>> " ld1 {v3.2d}, [%[key]], #16 ;"
>> " bpl 1b ;"
>> " aesdv0.16b, v2.16b ;"
>> " eor v0.16b, v0.16b, v3.16b ;"
>> " st1 {v0.16b}, %[out];"
>>
>> : [out] "=Q"(*out),
>> [key] "=r"(dummy0),
>> [rounds]"=r"(dummy1)
>> : [in]"Q"(*in),
>> "1"(ctx->key_dec),
>> "2"(num_rounds(ctx) - 2)
>> : "cc");
>>
>> kernel_neon_end();
>> }
>>
>> Now without this patch the compiler behaved like the following. It was
>> invoked with:
>>
>> aarch64-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.aes-ce-cipher.o.d
>> -nostdinc -isystem
>> /var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/bin/../lib/gcc/aarch64-linux-gnu/5.2.1/include
>> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/include
>> -Iarch/arm64/include/generated/uapi -Iarch/arm64/include/generated
>> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include
>> -Iinclude
>> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/include/uapi
>> -Iarch/arm64/include/generated/uapi
>> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include/uapi
>> -Iinclude/generated/uapi -include
>> /var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/include/linux/kconfig.h
>>
>> -I/var/fpwork/rschiele/crossbuild/builds/aarch64-linux-gnu/linux-next/srcdir/src/linux/arch/arm64/crypto
>> -Iarch/arm64/crypto -D__KERNEL__ -mlittle-endian -Wall -Wundef
>> -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
>> -Werror-implicit-function-declaration -Wno-format-security -std=gnu89
>> -mgeneral-regs-only -fno-delete-null-pointer-checks -O2
>> --param=allow-store-data-races=0 -Wframe-larger-than=2048
>> -fno-stack-protector -Wno-unused-but-set-variable
>> -fno-omit-frame-pointer -fno-optimize-sibling-calls
>> -fno-var-tracking-assignments -g -Wdeclaration-after-statement
>> -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
>> -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time
>> -DCC_HAVE_ASM_GOTO -Werror -march=armv8-a+crypto
>> -D"KBUILD_STR(s)=#s" -D"KBUILD_B
[ACTIVITY]
== Progress == * Ill (4/10) * Support (1/10) - Bugzilla issues (PR20490, PR24635, PR24350, PR20025, PR25720, PR25722) * Benchmarks (1/10) - Checking some previous benchmark results on A57 * Buildbots (2/10) - Getting AArch64 full bot back to rotation, since it's stable now - Re-enabling libc++ prototypes on local master - Bisecting broken test-suite - Another power cut in the office sent all the bots down... :( * Background (2/10) - Code review, meetings, discussions, general support, etc. - Validating some old sanitizer bugs - FOSDEM admin ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: incomplete .arch specifiers with latest Linaro gcc5 patches on armv8?
Hi Yvan, On Fri, Dec 4, 2015 at 6:57 PM, Yvan Roux wrote: > On 4 December 2015 at 16:47, Yvan Roux wrote: >> Hmmm, this seems to be triggered by -mgeneral-regs-only flag, at least >> on my side, I've to investigate more to give you a real answer, this >> backport is not a small one ;) But do you confirm that if you remove >> that flag the .arch are correct ? I will check that on Monday when I am back in the office or even better... > Kyrill submitted a patch for that issue which was lost in the pile and > approved today: > > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00576.html > > I'll backport it in our branch as soon as it is committed on trunk. ... I will apply that patch to our tree since the description and code change seems to exactly describe my observed behavior and I will provide you feedback on the results. Robert ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
