[ACTIVITY] 18-22 April 2016

[Diana Picus]

== Progress ==

* Inline assembly constraints support for ARM [TCWG-560] [1/10]
- Started investigating Bug24071

* Intro to LLVM buildbots [1/10]
- Got accustomed to the buildbot monitoring page
- Learned how to connect to the bots/perform really basic maintenance

* Misc [8/10]
- Onboarding checklists, policies, meetings etc [6/10]
- Laptop setup [2/10]

== Plan ==
* Inline assembly constraints support for ARM [TCWG-560]
- More investigations for Bug24071

* Misc
- Finish reading Octopus policies
- Review scripts for working with LLVM

[Christophe Lyon]

* 3 days off

== Progress ==
* Validation:
- fixed ABE master and stable branches to use 'ssh -t' instead of
'ssh -tt' when cross-testing
- trying to assert master vs stable before the array branch merge,
noticed differences on armv8l
- created linaro-local/stable Dejagnu branch (currently a copy of
master). Prepared ABE config patches to use it.

* GCC
- infrastructure problems (ST compute farm), leading to a lot of
noise in the validations (and wrong regression reports upstream)
- enabled gcc-6-branch monitoring
- added GCC-6 tab to the backports spreadsheet

* Support
- Windows-hosted toolchain crashes: it seems the builders we use to
make the release run Jessie and not Trusty. Tried to rebuild a
toolchain in a Jessie chroot, but the script failed (works under
Trusty)

* Misc (conf-calls, meetings, emails, ...)

== Next ==
* Validation
- check that using linaro-local/stable Dejagnu branch works well
- create validation reference points before array branch merge
- understand/fix armv8l validation differences between master/stable
ABE branches

* GCC
- trunk monitoring, report regressions if needed
- more intrinsics tests

* Support
- Windows-hosted toolchain bug

* Snapshots
- prepare a few backports for our gcc-5 branch

* Cortex-strings update

[Rob Savoye]

  As a note, all the builders we use for binary releases run Trusty still. I haven't tried Jessie (should work fine),but I know that newer Mingw releases fail to compile GCC 5.x.
- rob -

-------- Original message --------
From: Christophe Lyon <***@linaro.org>
Date: 04/22/2016 14:00 (GMT-07:00)
To: Linaro Toolchain Mailman List <linaro-***@lists.linaro.org>
Subject: [ACTIVITY] 18-22 April 2016

* 3 days off

== Progress ==
* Validation:
  - fixed ABE master and stable branches to use 'ssh -t' instead of
'ssh -tt' when cross-testing
  - trying to assert master vs stable before the array branch merge,
noticed differences on armv8l
  - created linaro-local/stable Dejagnu branch (currently a copy of
master). Prepared ABE config patches to use it.

* GCC
  - infrastructure problems (ST compute farm), leading to a lot of
noise in the validations (and wrong regression reports upstream)
  - enabled gcc-6-branch monitoring
  - added GCC-6 tab to the backports spreadsheet

* Support
  - Windows-hosted toolchain crashes: it seems the builders we use to
make the release run Jessie and not Trusty. Tried to rebuild a
toolchain in a Jessie chroot, but the script failed (works under
Trusty)

* Misc (conf-calls, meetings, emails, ...)

== Next ==
* Validation
  - check that using linaro-local/stable Dejagnu branch works well
  - create validation reference points before array branch merge
  - understand/fix armv8l validation differences between master/stable
ABE branches

* GCC
  - trunk monitoring, report regressions if needed
  - more intrinsics tests

* Support
  - Windows-hosted toolchain bug

* Snapshots
  - prepare a few backports for our gcc-5 branch

* Cortex-strings update

[Jim Wilson]

Post by Rob Savoye
As a note, all the builders we use for binary releases run Trusty still. I
haven't tried Jessie (should work fine),
but I know that newer Mingw releases fail to compile GCC 5.x.

In the weekly status meeting, Maxim and Christophe looked at the Mingw
build jobs, and said that they are running on the Hetzners, which are
running Jessie.

I can confirm that an abe toolchain build on a Debian 8.4 Jessie
machine reproduces the Mingw failures reported in 2073 and 2174. An
abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not
reproduce the same failures. Jessie has a 4.9.1 mingw cross
toolchain. Trusty has a 4.8.2 mingw cross toolchain. This could be a
bug in the gcc-4.9.1 release, or it could be a bug with the debian
jessie build of the mingw toolchain. I haven't tried debugging the
jessie 4.9.1 mingw cross toolchain yet.

I can confirm that an abe toolchain build using -O -g for the gcc
build instead of -O2 -g produces a working toolchain that does not
fail for the 2073 and 2174 testcases. The patch I used for this is
attached. I haven't done any testing other than those testcases, so I
don't know if this is really a good toolchain or not.

FYI While looking at this, I ran into two abe build problems.
1) A mingw toolchain build with --disable update fails with a gdb
configure error saying that Python.h can't be found.
The problem here is that PYTHON_MINGW env var needs to be set in order
to find the python header files. This is set in
checkout_infrastructure. But checkout_infrastructure is not called
when --disable update, so the env var doesn't get set, and the build
fails. The env var should be set somewhere else, or maybe set in both
the checkout and build functions.
2) A mingw toolchain rebuild after a gcc change fails with a
libsanitize error saying the scsi/scsi.h is missing.
The problem here is that the the linux kernel headers-install makefile
rule is run, which installs header files, and also removes header
files that the kernel doesn't think should be there. scsi/scsi.h is
one of the files that is removed, which was installed by glibc. The
glibc install is not redone, because glibc doesn't need to be rebuilt.
Then gcc gets rebuilt, and notices that the scsi/scsi.h file is
missing and fails. This problem can presumably be worked around by
using "---build gcc" on the abe command line, if you know that only
gcc needs to be rebuilt. I didn't reproduce this, or fully
investigate it, so it is possible that there is something else going
on here.

Jim

[Christophe Lyon]

Post by Jim Wilson

Post by Rob Savoye
As a note, all the builders we use for binary releases run Trusty still. I
haven't tried Jessie (should work fine),
but I know that newer Mingw releases fail to compile GCC 5.x.

In the weekly status meeting, Maxim and Christophe looked at the Mingw
build jobs, and said that they are running on the Hetzners, which are
running Jessie.

Strictly speaking, I couldn't confirm the OS version myself, since
I cannot connect to the builders :)

Post by Jim Wilson
I can confirm that an abe toolchain build on a Debian 8.4 Jessie
machine reproduces the Mingw failures reported in 2073 and 2174. An

Good to know!
On my side, I have so far been unable to build a Mingw toolchain
in our Jessie (8.3) build chroot.
I'm using ABE's scripts/MakeRelease.job, which succeeds on trusty.

Post by Jim Wilson
abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not
reproduce the same failures. Jessie has a 4.9.1 mingw cross
toolchain. Trusty has a 4.8.2 mingw cross toolchain. This could be a
bug in the gcc-4.9.1 release, or it could be a bug with the debian
jessie build of the mingw toolchain. I haven't tried debugging the
jessie 4.9.1 mingw cross toolchain yet.

That's what I feared.

Post by Jim Wilson
I can confirm that an abe toolchain build using -O -g for the gcc
build instead of -O2 -g produces a working toolchain that does not
fail for the 2073 and 2174 testcases. The patch I used for this is
attached. I haven't done any testing other than those testcases, so I
don't know if this is really a good toolchain or not.

Thanks for the investigation, this is quite helpful.

Post by Jim Wilson
FYI While looking at this, I ran into two abe build problems.

I noticed them, too.

Post by Jim Wilson
1) A mingw toolchain build with --disable update fails with a gdb
configure error saying that Python.h can't be found.
The problem here is that PYTHON_MINGW env var needs to be set in order
to find the python header files. This is set in
checkout_infrastructure. But checkout_infrastructure is not called
when --disable update, so the env var doesn't get set, and the build
fails. The env var should be set somewhere else, or maybe set in both
the checkout and build functions.
2) A mingw toolchain rebuild after a gcc change fails with a
libsanitize error saying the scsi/scsi.h is missing.
The problem here is that the the linux kernel headers-install makefile
rule is run, which installs header files, and also removes header
files that the kernel doesn't think should be there. scsi/scsi.h is
one of the files that is removed, which was installed by glibc. The
glibc install is not redone, because glibc doesn't need to be rebuilt.
Then gcc gets rebuilt, and notices that the scsi/scsi.h file is
missing and fails. This problem can presumably be worked around by
using "---build gcc" on the abe command line, if you know that only
gcc needs to be rebuilt. I didn't reproduce this, or fully
investigate it, so it is possible that there is something else going
on here.
Jim

[Christophe Lyon]

Post by Christophe Lyon

Post by Jim Wilson

Post by Rob Savoye
As a note, all the builders we use for binary releases run Trusty still. I
haven't tried Jessie (should work fine),
but I know that newer Mingw releases fail to compile GCC 5.x.

In the weekly status meeting, Maxim and Christophe looked at the Mingw
build jobs, and said that they are running on the Hetzners, which are
running Jessie.

Strictly speaking, I couldn't confirm the OS version myself, since
I cannot connect to the builders :)

Post by Jim Wilson
I can confirm that an abe toolchain build on a Debian 8.4 Jessie
machine reproduces the Mingw failures reported in 2073 and 2174. An

Good to know!
On my side, I have so far been unable to build a Mingw toolchain
in our Jessie (8.3) build chroot.
I'm using ABE's scripts/MakeRelease.job, which succeeds on trusty.

I forgot to mention that it fails while configuring mpfr for mingw: it complains
it cannot find gmp, although it built it just before trying to configure mpfr.

mpfr's config.log contains:
configure:15555: gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -g -O2 -ffloat-store
-I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include
-L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib
conftest.c -lgmp >&5
/usr/bin/ld: skipping incompatible
/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a
when searching for -lgmp
/usr/bin/ld: cannot find -lgmp

I am in an x86_64 jessie chroot.

Post by Christophe Lyon

Post by Jim Wilson
abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not
reproduce the same failures. Jessie has a 4.9.1 mingw cross
toolchain. Trusty has a 4.8.2 mingw cross toolchain. This could be a
bug in the gcc-4.9.1 release, or it could be a bug with the debian
jessie build of the mingw toolchain. I haven't tried debugging the
jessie 4.9.1 mingw cross toolchain yet.

That's what I feared.

Post by Jim Wilson
I can confirm that an abe toolchain build using -O -g for the gcc
build instead of -O2 -g produces a working toolchain that does not
fail for the 2073 and 2174 testcases. The patch I used for this is
attached. I haven't done any testing other than those testcases, so I
don't know if this is really a good toolchain or not.

Thanks for the investigation, this is quite helpful.

Post by Jim Wilson
FYI While looking at this, I ran into two abe build problems.

I noticed them, too.

Post by Jim Wilson
1) A mingw toolchain build with --disable update fails with a gdb
configure error saying that Python.h can't be found.
The problem here is that PYTHON_MINGW env var needs to be set in order
to find the python header files. This is set in
checkout_infrastructure. But checkout_infrastructure is not called
when --disable update, so the env var doesn't get set, and the build
fails. The env var should be set somewhere else, or maybe set in both
the checkout and build functions.
2) A mingw toolchain rebuild after a gcc change fails with a
libsanitize error saying the scsi/scsi.h is missing.
The problem here is that the the linux kernel headers-install makefile
rule is run, which installs header files, and also removes header
files that the kernel doesn't think should be there. scsi/scsi.h is
one of the files that is removed, which was installed by glibc. The
glibc install is not redone, because glibc doesn't need to be rebuilt.
Then gcc gets rebuilt, and notices that the scsi/scsi.h file is
missing and fails. This problem can presumably be worked around by
using "---build gcc" on the abe command line, if you know that only
gcc needs to be rebuilt. I didn't reproduce this, or fully
investigate it, so it is possible that there is something else going
on here.
Jim

[Jim Wilson]

On Sun, Apr 24, 2016 at 12:25 PM, Christophe Lyon

Post by Christophe Lyon
configure:15555: gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -g -O2 -ffloat-store
-I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include
-L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib
conftest.c -lgmp >&5
/usr/bin/ld: skipping incompatible
/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a
when searching for -lgmp
/usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.

It did find a libgmp, it just couldn't use it because it was for a
different target/ABI.

"gcc" is the wrong compiler for a mingw mpfr build. That should be
i686-w64-mingw32-gcc instead. I see that gmp forces use of -m32 for
the build. That is harmless for the mingw32 compiler which only emits
32-bit code. But if gmp was also built with "gcc", then you would
have a 32-bit x86-linux libgmp and a 64-bit x86_64-linux libmfpr which
can't be linked together. So I would suspect that they were both
built with the wrong compiler. Not obvious what is wrong, but if you
tried a build with CC=gcc in your environment, then it might fail this
way.

Jim

[Christophe Lyon]

Post by Jim Wilson
On Sun, Apr 24, 2016 at 12:25 PM, Christophe Lyon

Post by Christophe Lyon
configure:15555: gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -g -O2 -ffloat-store
-I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include
-L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib
conftest.c -lgmp >&5
/usr/bin/ld: skipping incompatible
/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a
when searching for -lgmp
/usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.

It did find a libgmp, it just couldn't use it because it was for a
different target/ABI.
"gcc" is the wrong compiler for a mingw mpfr build. That should be
i686-w64-mingw32-gcc instead. I see that gmp forces use of -m32 for
the build. That is harmless for the mingw32 compiler which only emits
32-bit code. But if gmp was also built with "gcc", then you would
have a 32-bit x86-linux libgmp and a 64-bit x86_64-linux libmfpr which
can't be linked together. So I would suspect that they were both
built with the wrong compiler. Not obvious what is wrong, but if you
tried a build with CC=gcc in your environment, then it might fail this
way.

I do not have such a variable in my environment.

Yet, on our Trusty machine we have gcc-mingw-w64 installed (with the
i686 and x86_64 variants), but not in the Jessie chroot.

That's probably why the build succeeds on Trusty.

Post by Jim Wilson
Jim

[Christophe Lyon]

Post by Christophe Lyon

Post by Jim Wilson
On Sun, Apr 24, 2016 at 12:25 PM, Christophe Lyon

Post by Christophe Lyon
configure:15555: gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -g -O2 -ffloat-store
-I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include
-L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib
conftest.c -lgmp >&5
/usr/bin/ld: skipping incompatible
/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a
when searching for -lgmp
/usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.

It did find a libgmp, it just couldn't use it because it was for a
different target/ABI.
"gcc" is the wrong compiler for a mingw mpfr build. That should be
i686-w64-mingw32-gcc instead. I see that gmp forces use of -m32 for
the build. That is harmless for the mingw32 compiler which only emits
32-bit code. But if gmp was also built with "gcc", then you would
have a 32-bit x86-linux libgmp and a 64-bit x86_64-linux libmfpr which
can't be linked together. So I would suspect that they were both
built with the wrong compiler. Not obvious what is wrong, but if you
tried a build with CC=gcc in your environment, then it might fail this
way.

I do not have such a variable in my environment.
Yet, on our Trusty machine we have gcc-mingw-w64 installed (with the
i686 and x86_64 variants), but not in the Jessie chroot.
That's probably why the build succeeds on Trusty.

Just to confirm: I've updated my chroot image (installed gcc-mingw-w64
& friends).
The build succeeded, and I was able to reproduce the compiler crash.

Post by Christophe Lyon

Post by Jim Wilson
Jim

[Michael Collison]

== This week ==

* Bugzilla 67321 - [ARM] Exploit Wide Add operations when appropriate (1)
- Re-based to GCC 6, re-validated and committed upstream

* Bugzilla 70008 - [ARM] Reverse subtract with carry can be generated in
thumb2 mode (1)
- Re-based and re-validated
- Need to create new bug as problem description does not match issue

* Bugzilla 70089 - ARM/THUMB unnecessarily typecasts some rvalues on
memory store (3/10)
- Developed new patch for arm that detects failures with negative numbers
- Debugging failures where constant is too large

* TCWG-247 - Create Validation Job to run on GCC Trunk Commit (3/10)
- Fleshed out additional portions of script and submitted for code review
- Still issues to be resolved in script as noted in git review

* Misc (2/10)
- Meetings
- Multiple interactions with ARM IT to configure and setup new laptop

== Next week ==

* TCWG-247
- Finish script

* Bugzilla 70089 - ARM/THUMB unnecessarily typecasts some rvalues on
memory store
- Finalize arm patch and validate

* Bugzilla 70008 - create new bug and submit upstream patch