[PATCH 0/3] glib-2.0: minor fixes and updates

[PATCH 0/3] glib-2.0: minor fixes and updates

[Andre McCurdy]

Andre McCurdy (3):
  glib-2.0: refresh configure-libtool.patch
  glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch
  glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

 .../add-march-i486-into-CFLAGS-automatically.patch | 39 ----------------------
 .../glib-2.0/glib-2.0/configure-libtool.patch      | 22 +++++++-----
 meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb      |  1 -
 meta/recipes-core/glib-2.0/glib.inc                |  4 ++-
 4 files changed, 17 insertions(+), 49 deletions(-)
 delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0/add-march-i486-into-CFLAGS-automatically.patch

-- 
1.9.1

[PATCH 1/3] glib-2.0: refresh configure-libtool.patch

[Andre McCurdy]

Refresh configure-libtool.patch to replace one more instance of
./libtool in configure.ac, first introduced in v2.31.20:

  https://git.gnome.org/browse/glib/commit/?id=59ee6dbc004adda8c4e4c8ff58bf21a9173eb99f

Fixes "./libtool: No such file or directory" warnings when running
configure:

 | ...
 | checking for dlsym in -ldl... yes
 | ../glib-2.46.2/configure: line 25481: ./libtool: No such file or directory
 | checking for RTLD_GLOBAL brokenness... (cached) yes
 | ...

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 .../glib-2.0/glib-2.0/configure-libtool.patch      | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch b/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
index 1d69a3f..aa5de27 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
+++ b/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
@@ -1,4 +1,4 @@
-From 1c5718648d49e795efee91c220a2bf9386c184f2 Mon Sep 17 00:00:00 2001
+From e8740833336c59d6f616a1781b256e648e338c26 Mon Sep 17 00:00:00 2001
 From: Martin Jansa <Martin.Jansa@gmail.com>
 Date: Sat, 28 Apr 2012 18:24:50 +0200
 Subject: [PATCH] configure: use $host_alias-libtool instead of libtool
@@ -13,19 +13,20 @@ from PATH though
 
 Rebased to glib-2.27.3 by Dongxiao Xu <dongxiao.xu@intel.com>
 Rebased to glib-2.32.1 by Martin Jansa <Martin.Jansa@gmail.com>
+Rebased to glib-2.31.20+ by Andre McCurdy <armccurdy@gmail.com>
 
 Upstream-Status: Inappropriate [configuration]
 
 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
 ---
- configure.ac |    8 ++++----
- 1 files changed, 4 insertions(+), 4 deletions(-)
+ configure.ac | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index a6478c6..9a93d60 100644
+index 1af90c5..f6b7a73 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -1470,7 +1470,7 @@ if test x"$glib_native_win32" = xyes; then
+@@ -1378,7 +1378,7 @@ if test x"$glib_native_win32" = xyes; then
    G_MODULE_LDFLAGS=
  else
    export SED
@@ -34,7 +35,7 @@ index a6478c6..9a93d60 100644
  fi
  dnl G_MODULE_IMPL= don't reset, so cmd-line can override
  G_MODULE_NEED_USCORE=0
-@@ -1535,9 +1535,9 @@ if test "$G_MODULE_IMPL" = "G_MODULE_IMPL_DL"; then
+@@ -1427,13 +1427,13 @@ AS_IF([ test "$G_MODULE_IMPL" = "G_MODULE_IMPL_DL" ], [
  	LDFLAGS="$LDFLAGS $G_MODULE_LDFLAGS"
  dnl *** check for OSF1/5.0 RTLD_GLOBAL brokenness
  	echo "void glib_plugin_test(void) { }" > plugin.c
@@ -46,7 +47,12 @@ index a6478c6..9a93d60 100644
  		${LDFLAGS} -module -o plugin.la -export-dynamic \
  		-shrext ".o" -avoid-version plugin.lo \
  		-rpath /dont/care >/dev/null 2>&1
-@@ -1614,7 +1614,7 @@ fi
+-	eval `./libtool --config | grep ^objdir`
++	eval `./$host_alias-libtool --config | grep ^objdir`
+ 	AC_CACHE_CHECK([for RTLD_GLOBAL brokenness],
+ 		glib_cv_rtldglobal_broken,[
+ 		AC_TRY_RUN([
+@@ -1506,7 +1506,7 @@ fi
  
  AC_MSG_CHECKING(for the suffix of module shared libraries)
  export SED
@@ -56,5 +62,5 @@ index a6478c6..9a93d60 100644
  module=yes eval std_shrext=$shrext_cmds
  # chop the initial dot
 -- 
-1.7.8.6
+1.9.1
 
-- 
1.9.1

[PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch

[Andre McCurdy]

The reasoning behind this patch isn't clear. ${CC} should always
contain appropriate -march flags. If the build is misconfigured
somehow (or someone is trying to build for i386) then we want the
configure scipt to generate an error, not to try to quietly try to
fix it (adding -march=i486 to CFLAGS is potentially going to cause
more problems than it solves).

Since this patch is unlikely to ever be merged upstream and it's not
helpful in any typical OE build, drop it rather than maintaining it.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 .../add-march-i486-into-CFLAGS-automatically.patch | 39 ----------------------
 meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb      |  1 -
 2 files changed, 40 deletions(-)
 delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0/add-march-i486-into-CFLAGS-automatically.patch

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/add-march-i486-into-CFLAGS-automatically.patch b/meta/recipes-core/glib-2.0/glib-2.0/add-march-i486-into-CFLAGS-automatically.patch
deleted file mode 100644
index 3aac35a..0000000
--- a/meta/recipes-core/glib-2.0/glib-2.0/add-march-i486-into-CFLAGS-automatically.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From 55253b55b9c65f3e0efbbe03cbab2a4c4014a16b Mon Sep 17 00:00:00 2001
-From: Song.Li <Song.Li@windriver.com>
-Date: Thu, 5 Jul 2012 15:09:41 +0800
-Subject: [PATCH] add -march=i486 into CFLAGS automatically
-
-Upstream-Status: Inappropriate [configuration]
-
-glib configure will check if current gcc need -march=i486,
-when gcc need -march=i486 but CFLAGS don't have,
-glib configure will abort and advise the user to add -march=i486 or later.
-This will break the build process,it's not good for automatic build system.
-so change this to adding -march=i485 automatically when it is needed.
----
- configure.ac |    6 ++++--
- 1 files changed, 4 insertions(+), 2 deletions(-)
-
-Index: glib-2.36.0/configure.ac
-===================================================================
---- glib-2.36.0.orig/configure.ac
-+++ glib-2.36.0/configure.ac
-@@ -2378,7 +2378,7 @@ dnl
- dnl Note that the atomic ops are only available with GCC on x86 when
- dnl using -march=i486 or higher.  If we detect that the atomic ops are
- dnl not available but would be available given the right flags, we want
--dnl to abort and advise the user to fix their CFLAGS.  It's better to do
-+dnl to add -march=i486 automatically to fix their CFLAGS.  It's better to do
- dnl that then to silently fall back on emulated atomic ops just because
- dnl the user had the wrong build environment.
-
-@@ -2401,7 +2401,8 @@ AC_CACHE_CHECK([for lock-free atomic int
-         AC_TRY_COMPILE([],
-                        [volatile int atomic = 2;\
-                         __sync_bool_compare_and_swap (&atomic, 2, 3);],
--                       [AC_MSG_ERROR([GLib must be build with -march=i486 or later.])],
-+                       [AC_MSG_WARN([GLib must be build with -march=i486 or later.])
-+                       SAVE_CFLAGS="${SAVE_CFLAGS} -march=i486"],
-                        [])
-         CFLAGS="${SAVE_CFLAGS}"
-       fi
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb
index 79643c7..5abb861 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb
@@ -7,7 +7,6 @@ SHRT_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
            file://configure-libtool.patch \
            file://fix-conflicting-rand.patch \
-           file://add-march-i486-into-CFLAGS-automatically.patch \
            file://glib-2.0-configure-readlink.patch \
            file://run-ptest \
            file://ptest-paths.patch \
-- 
1.9.1

Re: [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch

[Randy MacLeod]

On 2016-01-27 06:28 PM, Andre McCurdy wrote:
> The reasoning behind this patch isn't clear. ${CC} should always
> contain appropriate -march flags. If the build is misconfigured
> somehow (or someone is trying to build for i386) then we want the
> configure scipt to generate an error, not to try to quietly try to
> fix it (adding -march=i486 to CFLAGS is potentially going to cause
> more problems than it solves).
>
> Since this patch is unlikely to ever be merged upstream and it's not
> helpful in any typical OE build, drop it rather than maintaining it.
>
> Signed-off-by: Andre McCurdy <armccurdy@gmail.com>

Jackie,

Do you remember why this patch was needed?

-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

Re: [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch

[Phil Blundell]

On Mon, 2016-02-01 at 17:23 -0500, Randy MacLeod wrote:
> Do you remember why this patch was needed?

The comments in the patch provide a fairly clear explanation of what
problem it was trying to solve.  But I agree with Andre that this cure
is in fact worse than the original disease.

In any case, the issue is probably moot because neither glibc nor musl
support cpus without cmpxchg any more.

p.

Re: [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch

[Huang, Jie (Jackie)]

> -----Original Message-----
> From: Phil Blundell [mailto:pb@pbcl.net]
> Sent: Tuesday, February 02, 2016 6:45 AM
> To: MacLeod, Randy
> Cc: Andre McCurdy; openembedded-core@lists.openembedded.org; Huang, Jie (Jackie)
> Subject: Re: [OE-core] [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch
> 
> On Mon, 2016-02-01 at 17:23 -0500, Randy MacLeod wrote:
> > Do you remember why this patch was needed?
> 
> The comments in the patch provide a fairly clear explanation of what
> problem it was trying to solve.  But I agree with Andre that this cure
> is in fact worse than the original disease.
> 
> In any case, the issue is probably moot because neither glibc nor musl
> support cpus without cmpxchg any more.

I'm not the author of that patch, just helped forwarding it.
It seems reasonable to drop it and we may get back to the issue
and solve it with a more proper way.

Thanks,
Jackie

> 
> p.
> 

[PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Andre McCurdy]

The original over-ride dates back to 2007:

  http://git.openembedded.org/openembedded-core/commit/?id=fc5366261e12c100e18dc1d9ef0b86b91500e355

There are no obvious issues seen now when building glib-2.0 v2.46.2
in thumb2 for Cortex A15.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/recipes-core/glib-2.0/glib.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc
index eff5997..14722db 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -54,7 +54,9 @@ FILES_${PN}-codegen = "${datadir}/glib-2.0/codegen/*.py"
 FILES_${PN}-bash-completion = "${sysconfdir}/bash_completion.d \
                                ${datadir}/bash-completion"
 
-ARM_INSTRUCTION_SET = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+
 USE_NLS = "yes"
 
 do_install_append () {
-- 
1.9.1

Re: [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Phil Blundell]

On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote:
> -ARM_INSTRUCTION_SET = "arm"
> +ARM_INSTRUCTION_SET_armv4 = "arm"
> +ARM_INSTRUCTION_SET_armv5 = "arm"

Although I agree that this is a net improvement over the old code in
almost all cases, this patch is not quite right.  The reason for the
original override is that there is assembler code in glib which won't
compile as Thumb-1 (but is ok in Thumb-2).  Thumb-2 is only available
in ARMv6T2 and newer architectures so with your patch it looks like
compilation on arm1136jf-s (which is ARMv6 not ARMv6T2) would now fail.

I recommend that we either:

1. Introduce a new, explicit "thumb1" override which can be enabled by
the appropriate arch-arm*.inc files, and make all the appropriate
recipes set ARM_INSTRUCTION_SET based on that; or

2. Introduce a new thumb1-compatible.inc file which contains lines like

ARM_INSTRUCTION_SET_glib-2.0 = "arm"

and let distros which want to support older ARMs and enable Thumb
include that file; or

3. Take the view that it's now nearly fifteen years since Thumb-2 was
introduced, OE-core no longer needs to pander explicitly to Thumb-1,
and we should just remove all this scar tissue entirely.  Distros that
do want to target Thumb-1 can still maintain the appropriate
compatibility stuff (which is probably only a dozen lines or so) for
themselves.

Personally I would favour #3. :-)

p.

Re: [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

On Thu, Mar 03, 2016 at 01:02:35PM +0000, Phil Blundell wrote:
> On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote:
> > -ARM_INSTRUCTION_SET = "arm"
> > +ARM_INSTRUCTION_SET_armv4 = "arm"
> > +ARM_INSTRUCTION_SET_armv5 = "arm"
> 
> Although I agree that this is a net improvement over the old code in
> almost all cases, this patch is not quite right.  The reason for the
> original override is that there is assembler code in glib which won't
> compile as Thumb-1 (but is ok in Thumb-2).  Thumb-2 is only available
> in ARMv6T2 and newer architectures so with your patch it looks like
> compilation on arm1136jf-s (which is ARMv6 not ARMv6T2) would now fail.

If the MACHINE doesn't have thumb in TUNE_FEATURES (for selected
DEFAULTTUNE) won't use -mthumb, so building on ARMv6 shouldn't fail
or I didn't get your point.

> I recommend that we either:
> 
> 1. Introduce a new, explicit "thumb1" override which can be enabled by
> the appropriate arch-arm*.inc files, and make all the appropriate
> recipes set ARM_INSTRUCTION_SET based on that; or
> 
> 2. Introduce a new thumb1-compatible.inc file which contains lines like
> 
> ARM_INSTRUCTION_SET_glib-2.0 = "arm"
> 
> and let distros which want to support older ARMs and enable Thumb
> include that file; or
> 
> 3. Take the view that it's now nearly fifteen years since Thumb-2 was
> introduced, OE-core no longer needs to pander explicitly to Thumb-1,
> and we should just remove all this scar tissue entirely.  Distros that
> do want to target Thumb-1 can still maintain the appropriate
> compatibility stuff (which is probably only a dozen lines or so) for
> themselves.

Except that oe-core still contains qemuarm which is armv5t and almost 
nobody is building it with thumb enabled in DISTRO config. I'm regularly
asking it to be enabled on autobuilder, but without luck:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717

> Personally I would favour #3. :-)
> 
> p.
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Phil Blundell]

On Thu, 2016-03-03 at 14:18 +0100, Martin Jansa wrote:
> On Thu, Mar 03, 2016 at 01:02:35PM +0000, Phil Blundell wrote:
> > On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote:
> > > -ARM_INSTRUCTION_SET = "arm"
> > > +ARM_INSTRUCTION_SET_armv4 = "arm"
> > > +ARM_INSTRUCTION_SET_armv5 = "arm"
> > 
> > Although I agree that this is a net improvement over the old code
> > in
> > almost all cases, this patch is not quite right.  The reason for
> > the
> > original override is that there is assembler code in glib which
> > won't
> > compile as Thumb-1 (but is ok in Thumb-2).  Thumb-2 is only
> > available
> > in ARMv6T2 and newer architectures so with your patch it looks like
> > compilation on arm1136jf-s (which is ARMv6 not ARMv6T2) would now
> > fail.
> 
> If the MACHINE doesn't have thumb in TUNE_FEATURES (for selected
> DEFAULTTUNE) won't use -mthumb, so building on ARMv6 shouldn't fail
> or I didn't get your point.

Well, right, clearly it won't fail if you don't select thumb at all,
but the same is true of armv4 and armv5 so by that line of argument the
overrides here are completely redundant.  If you enable thumb on ARMv6
then glib-2.0 fails to build in the same way as it would have done for
armv4/armv5 without the overrides on ARM_INSTRUCTION_SET.

(Admittedly though, if you actually try to enable thumb with ARMv6 then
there are other problems that you need to fix before you can get as far
as even trying to compile glib-2.0.  This is perhaps further evidence
that nobody is doing this in practice!)

> 
> > 3. Take the view that it's now nearly fifteen years since Thumb-2
> > was
> > introduced, OE-core no longer needs to pander explicitly to Thumb-
> > 1,
> > and we should just remove all this scar tissue entirely.  Distros
> > that
> > do want to target Thumb-1 can still maintain the appropriate
> > compatibility stuff (which is probably only a dozen lines or so)
> > for
> > themselves.
> 
> Except that oe-core still contains qemuarm which is armv5t and
> almost 
> nobody is building it with thumb enabled in DISTRO config. 

Right, and the point I was trying to make is that, in this day and age,
it's not obvious that supporting Thumb1 is an important goal for oe-
core (because Thumb1 is sufficiently limited in both capabilities and
performance that anybody who wants Thumb-state will be using a Thumb2
capable cpu, and anybody who is stuck with an older cpu will be using
ARM-state).  

If nobody, or almost nobody, is actually building a Thumb1
configuration then this would seem to indicate that this is just an
obsolete technology and nobody would mind very much if support for it
were removed from oe-core.

p.

Re: [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Andre McCurdy]

On Thu, Mar 3, 2016 at 6:00 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Thu, 2016-03-03 at 14:18 +0100, Martin Jansa wrote:
>> On Thu, Mar 03, 2016 at 01:02:35PM +0000, Phil Blundell wrote:
>> > On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote:
>> > > -ARM_INSTRUCTION_SET = "arm"
>> > > +ARM_INSTRUCTION_SET_armv4 = "arm"
>> > > +ARM_INSTRUCTION_SET_armv5 = "arm"
>> >
>> > Although I agree that this is a net improvement over the old code
>> > in
>> > almost all cases, this patch is not quite right.  The reason for
>> > the
>> > original override is that there is assembler code in glib which
>> > won't
>> > compile as Thumb-1 (but is ok in Thumb-2).  Thumb-2 is only
>> > available
>> > in ARMv6T2 and newer architectures so with your patch it looks like
>> > compilation on arm1136jf-s (which is ARMv6 not ARMv6T2) would now
>> > fail.
>>
>> If the MACHINE doesn't have thumb in TUNE_FEATURES (for selected
>> DEFAULTTUNE) won't use -mthumb, so building on ARMv6 shouldn't fail
>> or I didn't get your point.
>
> Well, right, clearly it won't fail if you don't select thumb at all,
> but the same is true of armv4 and armv5 so by that line of argument the
> overrides here are completely redundant.  If you enable thumb on ARMv6
> then glib-2.0 fails to build in the same way as it would have done for
> armv4/armv5 without the overrides on ARM_INSTRUCTION_SET.
>
> (Admittedly though, if you actually try to enable thumb with ARMv6 then
> there are other problems that you need to fix before you can get as far
> as even trying to compile glib-2.0.  This is perhaps further evidence
> that nobody is doing this in practice!)
>
>>
>> > 3. Take the view that it's now nearly fifteen years since Thumb-2
>> > was
>> > introduced, OE-core no longer needs to pander explicitly to Thumb-
>> > 1,
>> > and we should just remove all this scar tissue entirely.  Distros
>> > that
>> > do want to target Thumb-1 can still maintain the appropriate
>> > compatibility stuff (which is probably only a dozen lines or so)
>> > for
>> > themselves.
>>
>> Except that oe-core still contains qemuarm which is armv5t and
>> almost
>> nobody is building it with thumb enabled in DISTRO config.
>
> Right, and the point I was trying to make is that, in this day and age,
> it's not obvious that supporting Thumb1 is an important goal for oe-
> core (because Thumb1 is sufficiently limited in both capabilities and
> performance that anybody who wants Thumb-state will be using a Thumb2
> capable cpu, and anybody who is stuck with an older cpu will be using
> ARM-state).
>
> If nobody, or almost nobody, is actually building a Thumb1
> configuration then this would seem to indicate that this is just an
> obsolete technology and nobody would mind very much if support for it
> were removed from oe-core.

I also vote for option 3.

All the good work and effort that Martin has been doing keeping the
Thumb1 builds alive could then perhaps be redirected to testing Thumb2
(or some other case which isn't covered by the default oe-core CI
builds).

> p.
>

Re: [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Phil Blundell]

On Thu, 2016-03-03 at 11:11 -0800, Andre McCurdy wrote:
> All the good work and effort that Martin has been doing keeping the
> Thumb1 builds alive could then perhaps be redirected to testing Thumb2
> (or some other case which isn't covered by the default oe-core CI
> builds).

Yes, agreed.  Given that, with modern processors and recent versions of
GCC, Thumb2 code is generally both smaller and faster than the
equivalent ARM binaries, it seems as though this is the configuration
that most users will want nowadays and consequently an important one to
test.

p.