# Progress #
* GDB is confused by the line table generated by GCC with -gcolumn-info
PR 22531. [2/5]
Tested one patch again, committed. Keep going on the rest
of them.
* Fix one GDB issue with OpenOCD, which is a long standing issue. [2/5]
Commit patch to both GDB master and 8.1 branch. Done.
* Misc, patches review, meeting. [1/5]
# Plan #
* One day off on Monday,
* PR 22531,
* Resume my pending patches on removing MAX_REGISTER_SIZE.
--
Yao Qi
== Progress ==
* GCC
- FDPIC
- rebased GCC and GDB patches on top of recent master branches.
- adjusted some of the GDB (gdbserver) patches to cope with gcc-8
complaints.
- adjusted CI testsuite to cope with gcc-8
* GCC upstream validation:
- no regression to report this week :-)
- still checking go/libgo random results on some tests
* Infrastructure:
- improved tcwg-buildapp (Using Lava, thanks to Remi). Now retries
lava job several times if needed.
- managed to configure postfix to send emails from our build
containers (thanks Ben). Once this is properly configured/deployed,
we'll finally be able to send GCC validation results to the
appropriate list
- resurrected my old work to force use of the old memcpy version
such that our binary toolchains work on older distros (such as
RHEL6...)
* misc (conf-calls, meetings, emails, ....)
== Next ==
* GCC/FDPIC
* GCC upstream validation
== This Week ==
* Code hoisting (TCWG-1234) (6/10)
- Working on approach to add basic block info to ANTIC sets
* GCC bugs (3/10)
- Extend sincos to handle sin 2x (PR83661): Patch completed.
* Misc (1/10)
- Meetings
# Progress #
* GDB is confused by the line table generated by GCC with -gcolumn-info
PR 22531. [2/5]
Override operator new/delete, patch is OK'ed but Tom still believes
classes must be is_trivially_destructible.
* Resume my pending patches on removing MAX_REGISTER_SIZE.
[2/5]
Patches v2 are updated and posted.
* Fix one GDB issue with OpenOCD, which is a long standing issue. [1/5]
Patch is tested, but not committed yet.
# Plan #
* PR 22531,
* Resume my pending patches on removing MAX_REGISTER_SIZE.
* More patches review,
--
Yao Qi
== Progress ==
* GCC
- FDPIC
- updated binutils ref results in CI. There are a couple of new
failures to investigate
- started GCC upgrade: rebased the FDPIC GCC pile of patches on top of
trunk.
- debugging ICE while building libgcc
* GCC upstream validation:
- helped reproduce a bugzilla on armeb
- reported random go/libgo test failures. Intel confirmed they also see
similar random results.
* Infrastructure:
- improved tcwg-buildapp script/job to actually boot arm/arm64 boards
after building a kernel with a given toolchain. (Using Lava, thanks to Remi)
* misc (conf-calls, meetings, emails, ....)
== Next ==
* GCC/FDPIC
* GCC upstream validation
== Progress ==
o LLVM
* "unpredictable" handling:
- Bugzilla 33011: Fix committed
- Working on unpredictable cases when using PC as operand.
* Buildbots failures:
- Analyzed regressions, due to D42574
- Tested and reviewed proposed tix
* 6.0.0 release test failure:
- Investigate Bug 35996 (asan_rt_conflict_test segfaults)
- Issue due to hardcoded filename;s lenght is too short
- Validating a fix
* Got commit after approval access granted
o Misc
* Various meetings and discussions.
# Progress #
* gfortran 7.2 vs 8.0 debug information difference. [2/5]
Open GCC bug to get more attention, PR debug/84131. It is a GCC 8
regression. Jakub fixed it two hours after I opened the bug. Now,
there is no gdb.fortran test fails with truk gcc.
* GDB is confused by the line table generated by GCC with -gcolumn-info
PR 22531. [2/5]
Patches are done, to be posted for review. Investigate how to
override new/delete operator in C++.
* Resume my pending patches on removing MAX_REGISTER_SIZE.
[1/5]
Update patch series v2 per reviewers' comments.
# Plan #
* GDB 8.1 is released! Bump up GDB version in Linaro toolchain.
* PR 22531,
* Resume my pending patches on removing MAX_REGISTER_SIZE.
--
Yao Qi
== This Week ==
* GCC bugs (5/10)
a) Extend malloc_candidate_p to handle multiple phi's (TCWG-1331):
Fixed testsuite regressions
b) Extend sincos to handle sin 2x (PR83661): Started working on patch.
* TCWG-1234 (2/10)
- A one liner patch that pessimizes hoisting by requiring an
expression to be in AVAIL blocks of all immediate successors works for
improving the regression.
- Working to make the patch more general to avoid pessimizing hoisting.
* Public holiday (2/10)
* Misc (1/10)
- Meetings
== Progress ==
o Linaro GCC/Validation
* 2018.01 snapshots deployed
* 2018.02 release candidates will be done when CVE mitigation will
be contributed upstream.
o LLVM
* "unpredictable" handling (Bugzilla 33011, ...): on-going
* Investigated OOM issue further... without much success.
* Python scripts reviews
o Misc
* Various meetings and discussions.
* Preparing Connect presentations
Note: working for Linaro every other week
== Progress ==
* PR35157 / TCWG-1308 (crash in ARM backend for VST1d64TPseudoWB_fixed
instruction):
+ after 2 attempts got now a clean patch with no testsuite regression
+ need to add testcase and it will be good to go upstream
* Track down why xdg-open launches libreoffice for .dot files and opened
Launchpad LP#1744953.
* Misc meetings
== Plan ==
* submit fix for PR35157 (crash in ARM backend for VST1d64TPseudoWB_fixed
instruction)
* fix for PR34170 / TCWG1137 (cannot select truncate in ARMv7 backend)
* start preparing slide for bswap/store merging passes presentation in
hacker room at Connect HK2018
# Progress #
* GDB is confused by the line table generated by GCC with -gcolumn-info
PR 22531. [2/5]
My preparatory patches are reviewed, mostly on C++, get encouraged to
use more fancy C++ features.
* gfortran 7.2 vs 8.0 debug information difference. [2/5]
Many gdb.fortran test fails with gfortran 8 but gfotran 7.2 is OK. I
'git bisect' gcc and find the commit causing the debug info change,
it is like a bug to me, but my compiler/fortran knowledge is too few
to claim it is a 7.2 -> 8.0 regression.
Posted my analysis to gcc@ and fortran@ mail list.
* TCWG-1040, SVE patches review. [1/5]
Review Alan's patches.
# Plan #
* PR 22531, upstream preparatory patches,
* Write patch series v2 for TCWG-1292.
--
Yao Qi
== Progress ==
* GCC
- FDPIC
- debugging CI loop
* GCC upstream validation:
- reported a few regressions
- contributed to jenkins jobs
* Infrastructure:
- looking at how to use lava to boot boards in gcc validation (with Remi)
* misc (conf-calls, meetings, emails, ....)
== Next ==
* GCC/FDPIC
* GCC upstream validation
Hi,
given the following code:
-- isystem_test.cpp -------------
#include < isystem_test.h>
bool dummy_function( void )
{
return false;
}
-----------------------------------------
-- isystem_test.h ------------------
template <class _CS_cT>
class allocator
{
};
-----------------------------------------
and g++ version: arm-eabi-g++.exe (Linaro GCC 7.2-2017.11)
1. compiling with "arm-eabi-g++ -I . -g -c isystem_test.cpp"
--> OK
2. compiling with " arm-eabi-g++ -isystem . -g -c isystem_test.cpp "
--> output error:
In file included from isystem_test.cpp:3:0:
./isystem_test.h:3:1: error: template with C linkage
template <class _CS_cT>
^~~~~~~~
It seams that the option -isystem changes the include of isystems_test.h into a C include, i.e. the header content seems to be handled as C-Code
Same error behavior with arm-eabi Linaro GCC 6.4-2017.11, Linaro GCC 6.3-2017.05
-----------------
Testing the same with the mingw msys g++ compiler outputs no error:
g++.exe (Rev2, Built by MSYS2 project) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---------------
Also no errors for:
arm-linux-gnueabihf-g++.exe (Linaro GCC 6.3-2017.05)
---------------
Is there a special behavior for arm-eabi g++ compiler?
Best regards
Martin Kaul
The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2018.01
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+svn254792 and
includes performance improvements and bug fixes backported from mainline GCC.
The contents of this snapshot will be part of the 2018.02 stable[2] quarterly
release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2018.01/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 7.2+svn256695
o Linaro GCC 6 monthly snapshot[1] is based on FSF GCC 6.4+svn254791 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-2018.01/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 6.4+svn256699
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.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
== Progress ==
o LLVM
* Bugzilla 33011 (MVN instruction "Upredictable" bit patterns incorrect):
- Working on upstream comments
* Working on more unpredictable handling in Tablegen
* Fixing an issue with registers class in peephole optimization
(exhibited by unpredictable patches).
* Buildbots babysitting: investigated OOM issue, offending patch reverted.
o Misc
* Various meetings and discussions.
# Progress #
* GDB is confused by the line table generated by GCC with -gcolumn-info
PR 22531. [2/5]
Chat with other two people who are changing the same file, and they
are OK to get my changes first. Commit one obvious patch, and testing
one patch series for refactor.
* TCWG-181, GDB compile feature. [2/5]
Many new test failures in gdb.compile, because it is not supported on
arm and aarch64, but we have no way to disable them. Commit two fixes
to get test better, but still many fails on arm-linux. I think I
still need a patch to disable the test form arm-linux.
* TCWG-1040, SVE patches review. [1/5]
Review Alan's patches.
# Plan #
* PR 22531, upstream preparatory patches,
* Answer questions to my pending patch series, TCWG-1292.
--
Yao Qi
== Progress ==
* GCC
- FDPIC
- fixed crash during program startup (self-relocation)
- CI loop now almost green
* GCC upstream validation:
- reported a few of regressions
- committed a few minor testsuite fixes
* Infrastructure:
* misc (conf-calls, meetings, emails, ....)
== Next ==
* GCC/FDPIC
* GCC upstream validation
Hi, all
I have updated my test case:
Compile passed but failed while linking.
wentao@ubuntu:~/test/lamda$ cat a.cc
#include <iostream>
using namespace std;
int main()
{
auto f = [=]() {
cout <<"Hello world"<<endl;
};
f();
return 0;
}
wentao@ubuntu:~/test/lamda$ arm-eabi-g++ --std=gnu++11 a.cc -o arm32
/home/wentao/TeeOS/tools/gcc-linaro-6.3.1-2017.05-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.3.1/../../../../arm-eabi/lib/libstdc++.a(locale.o): In function `get_locale_cache_mutex':
/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/snapshots/gcc.git~linaro-6.3-2017.05/libstdc++-v3/src/c++98/locale.cc:36: undefined reference to `__sync_synchronize'
/home/wentao/TeeOS/tools/gcc-linaro-6.3.1-2017.05-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.3.1/../../../../arm-eabi/lib/libstdc++.a(future.o): In function `__future_category_instance':
/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/snapshots/gcc.git~linaro-6.3-2017.05/libstdc++-v3/src/c++11/future.cc:64: undefined reference to `__sync_synchronize'
/home/wentao/TeeOS/tools/gcc-linaro-6.3.1-2017.05-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.3.1/../../../../arm-eabi/lib/libstdc++.a(locale_init.o): In function `(anonymous namespace)::get_locale_mutex()':
/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/snapshots/gcc.git~linaro-6.3-2017.05/libstdc++-v3/src/c++98/locale_init.cc:66: undefined reference to `__sync_synchronize'
collect2: error: ld returned 1 exit status
wentao@ubuntu:~/test/lamda$
������: zhangwentao (M)
����ʱ��: 2018��1��10�� 10:22
�ռ���: 'linaro-toolchain(a)lists.linaro.org'
����: Huangqiang (H); Lizefan; leijitang
����: Does linaro toolchain support c++11 ??
Hi all,
I wonder if my compiler supports C++11? If not, where could I found the compiler supports c++11 (both 32bit and 64bit arm).
THANKS a lot~~~
My compiler information is as below:
wentao@ubuntu:~/test/lamda$ arm-eabi-g++ -v
Using built-in specs.
COLLECT_GCC=arm-eabi-g++
COLLECT_LTO_WRAPPER=/home/wentao/TeeOS/tools/gcc-linaro-6.3.1-2017.05-x86_64_arm-eabi/bin/../libexec/gcc/arm-eabi/6.3.1/lto-wrapper
Target: arm-eabi
Configured with: '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/snapshots/gcc.git~linaro-6.3-2017.05/configure' SHELL=/bin/bash --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/_build/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared --without-included-gettext --enable-nls --disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id --disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu --enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no --enable-multilib --with-multilib-list=aprofile --enable-threads=no --disable-multiarch --with-newlib --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/_build/sysroots/arm-eabi --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/_build/builds/destdir/x86_64-unknown-linux-gnu/arm-eabi/libc --enable-checking=release --disable-bootstrap --enable-languages=c,c++,lto --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-eabi --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-eabi/_build/builds/destdir/x86_64-unknown-linux-gnu
Thread model: single
gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05)
wentao@ubuntu:~/test/lamda$
===>
And more, I wrote a ��hello-world�� program using c++11, it could work with host g++, but when I change to ��arm-eabi-g++��, it does not work.
Information as below:
wentao@ubuntu:~/test/lamda$ cat a.cc
#include <iostream>
using namespace std;
typedef void(*Func)();
int main()
{
Func f = [=]() {
cout <<"Hello world"<<endl;
};
f();
return 0;
}
wentao@ubuntu:~/test/lamda$ g++ a.cc -o host
a.cc: In function ��int main()��:
a.cc:10:2: warning: lambda expressions only available with -std=c++11 or -std=gnu++11 [enabled by default]
};
^
wentao@ubuntu:~/test/lamda$ ./host
Hello world
wentao@ubuntu:~/test/lamda$ arm-eabi-g++ a.cc -o arm32
a.cc: In function ��int main()��:
a.cc:10:2: error: cannot convert ��main()::<lambda()>�� to ��Func {aka void (*)()}�� in initialization
};
^
wentao@ubuntu:~/test/lamda$ arm-eabi-g++ --std=gnu++11 a.cc -o arm32 # if gives �Cstd=c++11 , the error is the same.
a.cc: In function ��int main()��:
a.cc:10:2: error: cannot convert ��main()::<lambda()>�� to ��Func {aka void (*)()}�� in initialization
};
^
wentao@ubuntu:~/test/lamda$
Hi everyone,
Note 1: Working on Linaro 50% time.
Note 2: had afternoons off for the first 2 weeks of January
== Progress ==
* Week 1 (2/1 -> 5/1) working for Arm
* Fix poor screen resolution issue
* Onboarding process:
+ read all docs, setup accounts (gmail, octopus, ...)
* PR35157 / TCWG-1308 (Crash in ARM backend for VST1d64TPseudoWB_fixed
instruction):
+ reproduce in llc under gdb, start investigating
== Plan ==
* PR35157 / TCWG-1308 (Crash in ARM backend for VST1d64TPseudoWB_fixed
instruction)
# Progress #
* GDB 8.1 release.
8.1 RC was created. 8.1 will be released soon, I think.
* GDB is confused by the line table generated by GCC with -gcolumn-info
PR 22531. [3/5]
Get a working patch, but need to upstream my refactoring first. Other
two people from upstream are also changing the same file, need to
cooperate.
* Upstream patches review, [2/5]
** Review changes to dwarf2read.c,
** Review one ARMv8 OpenOCD patch,
# Plan #
* PR 22531,
* Resume my pending patches on removing MAX_REGISTER_SIZE.
--
Yao Qi
