== Progress ==
* GCC
- FDPIC: started reading docs
- testsuite cleanup
* GCC upstream validation:
- reported 2 bugs in qemu-armeb
- noise reduction: polishing dejagnu local patches
- since ubsan merge with upstream, validation of arm targets is now
much longer (typically 1h30 to 6h), leading to timeouts most of the
time
* Infrastructure:
- improved GCC bisect job/scripts
- updated ABE to allow overriding cpu/fpu/tune/arch etc...
* misc (conf-calls, meetings, emails, ....)
== Next ==
* GCC upstream validation
* GCC/ubsan
* GCC/FDPIC
The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2017.10
snapshot of Linaro GCC 6 and 7 source packages.
o The GCC 7 series introduced an ABI change for ARM targets by fixing a bug
(present since GCC 5, see link below) that affects conformance to the
procedure
call standard (AAPCS). The bug affects some C++ code where class objects
are
passed by value to functions and could result in incorrect or inconsistent
code
being generated. If the option -Wpsabi is enabled (on by default) the
compiler
will emit a diagnostic note for code that might be affected by this ABI
change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
For an explanation of the changes please see the following website:
https://gcc.gnu.org/gcc-7/changes.html
o Linaro GCC 7 monthly snapshot[1] is based on FSF GCC 7.2+svn253626 and
includes performance improvements and bug fixes backported from mainline
GCC.
The contents of this snapshot will be part of the 2017.11 stable[2]
quarterly
release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.10/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 7.2+svn253626
o Linaro GCC 6 monthly snapshot[1] is based on FSF GCC 6.4+svn253668 and
includes performance improvements and bug fixes backported from mainline
GCC.
This snapshot contents will be part of the next maintenance release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.4-2017.10/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 6.4+svn253668
o 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.
== Progress ==
o Linaro GCC/Validation
* Continue releases handover
- Branch merges done
- Monthly snapshots about to be deployed
o LLVM
* Jira cards review
* Checked/updated cards related to upstream BZ
* Continue ramp-up
o Misc
* Various meetings and discussions.
== Plan ==
o Continue release handover and LLVM ramp-up
== This Week ==
* TCWG-1234 (5/10)
- Posted analysis upstream with a test-case.
- Have a workaround that disables hoisting when only single stmt is to
be hoisted.
- Investigating solution to limit distance between hoisted def. and it's uses.
* TCWG-1005 (2/10)
- Did changes based on upstream feedback from Honza, validated patch.
- Waiting for final approval from Honza before committing.
* Sick leave (2/10)
* Misc (1/10)
- Meetings
== Next Week ==
- TCWG-1234, TCWG-1005
* One day off after Connect
== Progress ==
o Linaro GCC/Validation
* Handover releases to ARM on-going.
o LLVM
* Continue ramp-up
o Misc
* Various meetings and discussions.
* Debrief Connect inside ST
== Plan ==
o Continue release handover
o LLVM Jira card: cleanup and find first tasks to do
== This Week ==
* TCWG-1234: code-hoisting regression (3/10)
- Have a workaround that fixes the particular regression (but may
introduce another)
- Trying to cross build benchmarks
- Investigating PRE and code-hoisting optimizations
* TCWG-1005: malloc attr propagation (3/10)
- Iteration based on upstream feedback.
* TCWG-1253 (1/10)
- Committed patch last week to add patterns for div and cmp against 0.
- Patch to transform rshift and cmp against 0 to cmp between operands
in upstream review.
* Public Holiday (2/10)
* Misc (1/10)
- Meetings
== Next Week ==
- TCWG-1234, TCWG-1005
== Connect ==
* Various discussions on GNU toolchain roadmap
== Progress ==
* GCC
- committed fix for PR71727 (strict-align bug on aarch64), backported
to gcc-7-branch
- small fixes in the testsuite
* GCC upstream validation:
- problems with internal infrastructure, but validation results OK
- reported a couple of regressions/new failures
- ran validations for a couple of tentative patches
- noise reduction: looking at how to report randomly killed processes
* misc (conf-calls, meetings, emails, ....)
- Connect feedback (internal)
== Next ==
* GCC upstream validation
* GCC/ubsan
* GCC/deprecated-IT blocks
# Progress #
* GDB SVE patches review. [4/10]
Finished my patches to remove the last use of MAX_REGISTER_SIZE. Send
them to Alan to review.
* GDB flexible target description follow-up. [4/10]
Committed some patches to improve GDB build, so that we can easily
share code of target description between GDB and GDBserver. Done.
* File Linaro Connect expense, and misc. [2/10]
# Plan #
* On holiday, Mon - Thu.
* Either GDB target description work,or ILP32 GDB branch.
--
Yao Qi
On 24 July 2017 at 18:38, Christophe Lyon <christophe.lyon(a)linaro.org> wrote:
>
>
> Le 24 juil. 2017 18:30, "Ard Biesheuvel" <ard.biesheuvel(a)linaro.org> a écrit
> :
>
> On 18 July 2017 at 13:54, Christophe Lyon <christophe.lyon(a)linaro.org>
> wrote:
>> On 13 July 2017 at 13:50, Christophe Lyon <christophe.lyon(a)linaro.org>
>> wrote:
>>> On 12 July 2017 at 19:33, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
>>> wrote:
>>>> On 12 July 2017 at 18:27, Alexei Fedorov <Alexei.Fedorov(a)arm.com> wrote:
>>>>>
>>>>> Christophe, Leif, Ard, Ryan at al.
>>>>>
>>>>>
>>>>> We are observing unaligned memory access fault with UEFI code compiled
>>>>> by
>>>>> Linaro GCC 6.3.1 & 7.1.1 using -O3 optimisation option.
>>>>>
>>>>> The fault occures at the very early stage of UEFI boot with MMU not
>>>>> being
>>>>> enabled yet.
>>>>>
>>>>> The failing function is CalculateSum8() from
>>>>> edk2\MdePkg\Library\BaseLib\CheckSum.c:
>>>>>
>>>>>
>>>>> UINT8
>>>>> EFIAPI
>>>>> CalculateSum8 (
>>>>> IN CONST UINT8 *Buffer,
>>>>> IN UINTN Length
>>>>> )
>>>>> {
>>>>> UINT8 Sum;
>>>>> UINTN Count;
>>>>>
>>>>> ASSERT (Buffer != NULL);
>>>>> ASSERT (Length <= (MAX_ADDRESS - ((UINTN) Buffer) + 1));
>>>>>
>>>>> for (Sum = 0, Count = 0; Count < Length; Count++) {
>>>>> Sum = (UINT8) (Sum + *(Buffer + Count));
>>>>> }
>>>>>
>>>>> return Sum;
>>>>> }
>>>>>
>>>>> & the instruction which causes the exception is "ldr q1, [x1], 16"
>>>>> which
>>>>> accesses Buffer = 0xE0000048 pointed by X1 register, see the part of
>>>>> generated assembly code:
>>>>>
>>>>>
>>>>> // r:\edk2\MdePkg\Library\BaseLib\CheckSum.c:49: for (Sum = 0, Count
>>>>> = 0;
>>>>> Count < Length; Count++) {
>>>>> .loc 1 49 0 is_stmt 1
>>>>> cbz x19, .L10 // Length,
>>>>> .L4:
>>>>> sub x0, x19, #1 // tmp150, Length,
>>>>> cmp x0, 14 // tmp150,
>>>>> bls .L11 //,
>>>>> // r:\edk2\MdePkg\Library\BaseLib\CheckSum.c:42: {
>>>>> .loc 1 42 0
>>>>> movi v0.4s, 0 // vect_Sum_19.24
>>>>> lsr x2, x19, 4 // bnd.18, Length,
>>>>> mov x1, x20 // ivtmp.29, Buffer
>>>>> mov x0, 0 // ivtmp.28,
>>>>> .LVL4:
>>>>> .p2align 3
>>>>> .L7:
>>>>> // r:\edk2\MdePkg\Library\BaseLib\CheckSum.c:50: Sum = (UINT8) (Sum
>>>>> +
>>>>> *(Buffer + Count));
>>>>> .loc 1 50 0 discriminator 3
>>>>> ldr q1, [x1], 16 // vect__6.23, MEM[(const UINT8
>>>>> *)vectp_Buffer.21_38]
>>>>> add x0, x0, 1 // ivtmp.28, ivtmp.28,
>>>>> cmp x0, x2 // ivtmp.28, bnd.18
>>>>> add v0.16b, v0.16b, v1.16b // vect_Sum_19.24, vect_Sum_19.24,
>>>>> vect__6.23
>>>>> bcc .L7 //,
>>>>>
>>>>> ...
>>>>>
>>>>> Although all AARCH64 code is compiled with "-mstrict-align" option
>>>>> which
>>>>> according to GCC 3.18.1 AArch64 Options:
>>>>>
>>>>> "-mstrict-align
>>>>>
>>>>> Avoid generating memory accesses that may not be aligned on a natural
>>>>> object
>>>>> boundary as described in the architecture specification."
>>>>>
>>>>>
>>>>> the generated code doesn't comply with this description. In this case
>>>>> X1 =
>>>>> Buffer @0xE0000048 and is not aligned to 16 bytes boundary.
>>>>>
>>>>> The similiar code is generated by GCC 6.3.1-2017.05 but 5.3.1-2016.05
>>>>> compiler produces only 16 bytes aligned memory accesses when loading Q1
>>>>> register.
>>>>>
>>>>>
>>>>> I attached the simple test file which can be compiled by running GCC
>>>>> compilation with
>>>>>
>>>>> -c test.c -O3 -mstrict-align -save-temps
>>>>>
>>>>> to see the difference between code generated by 7.1.1 & 5.3.1 GCC
>>>>> versions.
>>>>>
>>>>> It seems that 5.3.1 ignores "-mstrict-align" option at all and always
>>>>> generates aligned pointers for loading Q1 register, 7.1.1 & 6.3.1 also
>>>>> ignore the option but generate slighly different code with unaligned
>>>>> access
>>>>> enabled.
>>>>>
>>>>>
>>>>> Please share your thoughts regading this issue.
>>>>>
>>>>
>>>> Hello Alexei,
>>>>
>>>> This does look like a compiler bug to me. 'Buffer' is a pointer to
>>>> unsigned char, and so the compiler should never emit the ldr
>>>> instruction under -mstrict-align.
>>>>
>>>> In the mean time, we could work around this with adding
>>>> -mgeneral-regs-only in all places where -mstrict-align is being
>>>> passed. In general, I don't really see the point of supporting the use
>>>> of FP/ASIMD registers in UEFI beyond ensuring that our builds are
>>>> compatible with 3rd party binaries that do use them.
>>>>
>>>
>>> Hello Alexei,
>>>
>>> I agree with Ard: it looks like a compiler bug, I'm looking at it.
>>>
>>> And indeed in the mean time, using -mgeneral-regs-only should
>>> workaround your problem.
>>>
>>
>> Hello,
>>
>> As a follow-up, I've posted a patch:
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html
>>
>> We'll see if maintainers agree.
>>
>
> Thanks. By the looks of it, nobody cared to respond, right?
>
>
> Not yet and we are used to slow response.
>
> In addition I'm on holidays until Aug 21st so I won't ping until then.
>
>
Hi all,
My patch was finally accepted last week and committed.
I also backported it to the gcc-7-branch, so that the problem will
be fixed in the next gcc-7 release (either FSF or Linaro).
Thanks,
Christophe
