[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Matt Weber]

Works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
which is an issue where the Microblaze archtecture had code that
caused a infinite recursion while optimizing in versions of GCC
less then 8.x.  More BR discussion can be found on this thread.
http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2018-04-25-td192721.html

Resolves:
http://autobuild.buildroot.net/results/b42d68c66d8ea035845a28c5530ef0682fd95713 (boost)
http://autobuild.buildroot.net/results/af976a4805fb8b3f0c17a8e3a1f901b2255caa0b (flare-engine)
http://autobuild.buildroot.net/results/d20/d20700bd538ba1e9d45ab8a61ecbbba1a320ef38 (gst-ffmpeg)

CC: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---

Changes
v1 - > v2
[Thomas P
 - Switched from doing a autobuilder filter to a toolchain bug.
   Note, a "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_8" will be needed
   once GCC8 merges.
---
 package/boost/Config.in                | 4 ++++
 package/flare-engine/Config.in         | 4 ++++
 package/gstreamer/gst-ffmpeg/Config.in | 4 ++++
 toolchain/Config.in                    | 5 +++++
 4 files changed, 17 insertions(+)

diff --git a/package/boost/Config.in b/package/boost/Config.in
index 0755d9c..ec0e19c 100644
--- a/package/boost/Config.in
+++ b/package/boost/Config.in
@@ -104,12 +104,16 @@ config BR2_PACKAGE_BOOST_FIBER
 	# mips support uses the "pause" instruction, only available
 	# since mips32r2/mips64r2.
 	depends on !BR2_MIPS_CPU_MIPS32 && !BR2_MIPS_CPU_MIPS64
+	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_85180
 	help
 	  C++11 userland threads library.
 
 comment "boost-fiber needs a toolchain w/ NPTL"
 	depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL
 
+comment "boost-fiber needs a toolchain not affected by GCC bug 85180"
+	depends on BR2_TOOLCHAIN_HAS_GCC_BUG_85180
+
 config BR2_PACKAGE_BOOST_FILESYSTEM
 	bool "boost-filesystem"
 	help
diff --git a/package/flare-engine/Config.in b/package/flare-engine/Config.in
index cdcb018..e299a6b 100644
--- a/package/flare-engine/Config.in
+++ b/package/flare-engine/Config.in
@@ -2,6 +2,7 @@ config BR2_PACKAGE_FLARE_ENGINE
 	bool "flare-engine"
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on !BR2_STATIC_LIBS # SDL2
+	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_85180
 	select BR2_PACKAGE_SDL2
 	select BR2_PACKAGE_SDL2_IMAGE
 	select BR2_PACKAGE_SDL2_MIXER
@@ -17,3 +18,6 @@ config BR2_PACKAGE_FLARE_ENGINE
 
 comment "flare-engine needs a toolchain w/ C++, dynamic library"
 	depends on !BR2_INSTALL_LIBSTDCPP || BR2_STATIC_LIBS
+
+comment "flare-engine needs a toolchain not affected by GCC bug 85180"
+	depends on BR2_TOOLCHAIN_HAS_GCC_BUG_85180
diff --git a/package/gstreamer/gst-ffmpeg/Config.in b/package/gstreamer/gst-ffmpeg/Config.in
index 32bfdd5..1e95d01 100644
--- a/package/gstreamer/gst-ffmpeg/Config.in
+++ b/package/gstreamer/gst-ffmpeg/Config.in
@@ -5,6 +5,7 @@ config BR2_PACKAGE_GST_FFMPEG
 	depends on !BR2_MIPS_CPU_MIPS32R6 && !BR2_MIPS_CPU_MIPS64R6
 	# triggers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151 on sh
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 || !BR2_sh
+	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_85180
 	select BR2_PACKAGE_GST_PLUGINS_BASE
 	help
 	  GStreamer plugin containing one plugin with a set of
@@ -28,3 +29,6 @@ endif
 
 comment "gst-ffmpeg needs a toolchain w/ gcc >= 5"
 	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5 && BR2_sh
+
+comment "gst-ffmpeg needs a toolchain not affected by GCC bug 85180"
+	depends on BR2_TOOLCHAIN_HAS_GCC_BUG_85180
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 2479a65..61424ec 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -84,6 +84,11 @@ config BR2_TOOLCHAIN_HAS_GCC_BUG_64735
 	default y if BR2_m68k_cf5208
 	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_7
 
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
+config BR2_TOOLCHAIN_HAS_GCC_BUG_85180
+	bool
+	default y if BR2_microblaze
+
 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85862
 # An infinite loop exists in the find_base_term() logic of 6.x
 # on microblaze.  http://autobuild.buildroot.net/results/158e8ebb39713e1b436a5cc1a1916f46c30694df/
-- 
1.9.1

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Thomas Petazzoni]

Hello,

On Mon, 28 May 2018 10:35:10 -0500, Matt Weber wrote:
> Works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
> which is an issue where the Microblaze archtecture had code that
> caused a infinite recursion while optimizing in versions of GCC
> less then 8.x.  More BR discussion can be found on this thread.
> http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2018-04-25-td192721.html
> 
> Resolves:
> http://autobuild.buildroot.net/results/b42d68c66d8ea035845a28c5530ef0682fd95713 (boost)
> http://autobuild.buildroot.net/results/af976a4805fb8b3f0c17a8e3a1f901b2255caa0b (flare-engine)
> http://autobuild.buildroot.net/results/d20/d20700bd538ba1e9d45ab8a61ecbbba1a320ef38 (gst-ffmpeg)
> 
> CC: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>

Thanks for your work on this!

So, only boost-fiber is affected inside the boost package ?

And passing -O0 or -O2 instead of -Os doesn't work around the problem ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Matthew Weber]

Thomas,

On Mon, May 28, 2018 at 2:29 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Mon, 28 May 2018 10:35:10 -0500, Matt Weber wrote:
> > Works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
> > which is an issue where the Microblaze archtecture had code that
> > caused a infinite recursion while optimizing in versions of GCC
> > less then 8.x.  More BR discussion can be found on this thread.
> > http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2018-04-25-td192721.html
> >
> > Resolves:
> > http://autobuild.buildroot.net/results/b42d68c66d8ea035845a28c5530ef0682fd95713 (boost)
> > http://autobuild.buildroot.net/results/af976a4805fb8b3f0c17a8e3a1f901b2255caa0b (flare-engine)
> > http://autobuild.buildroot.net/results/d20/d20700bd538ba1e9d45ab8a61ecbbba1a320ef38 (gst-ffmpeg)
> >
> > CC: Romain Naour <romain.naour@gmail.com>
> > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
>
> Thanks for your work on this!
>
> So, only boost-fiber is affected inside the boost package ?

Correct, I dissected it back to parts of boost would fail but when
built without fiber enabled they were fine.

>
> And passing -O0 or -O2 instead of -Os doesn't work around the problem ?
>

I tried O0/1/2 without luck.  I just checked though that they were
actually being used in the verbose boost output and turns out boost is
forcing a O3 as the last O value in the flags.  So there's a bug....
I'll see if I can reasonably fix that  and retest.

Matt

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Matthew Weber]

Thomas,

On Mon, May 28, 2018 at 2:50 PM, Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
> Thomas,
>
> On Mon, May 28, 2018 at 2:29 PM, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>>
>> Hello,
>>
>> On Mon, 28 May 2018 10:35:10 -0500, Matt Weber wrote:
>> > Works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
>> > which is an issue where the Microblaze archtecture had code that
>> > caused a infinite recursion while optimizing in versions of GCC
>> > less then 8.x.  More BR discussion can be found on this thread.
>> > http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2018-04-25-td192721.html
>> >
>> > Resolves:
>> > http://autobuild.buildroot.net/results/b42d68c66d8ea035845a28c5530ef0682fd95713 (boost)
>> > http://autobuild.buildroot.net/results/af976a4805fb8b3f0c17a8e3a1f901b2255caa0b (flare-engine)
>> > http://autobuild.buildroot.net/results/d20/d20700bd538ba1e9d45ab8a61ecbbba1a320ef38 (gst-ffmpeg)
>> >
>> > CC: Romain Naour <romain.naour@gmail.com>
>> > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
>>
>> Thanks for your work on this!
>>
>> So, only boost-fiber is affected inside the boost package ?
>
> Correct, I dissected it back to parts of boost would fail but when
> built without fiber enabled they were fine.
>
>>
>> And passing -O0 or -O2 instead of -Os doesn't work around the problem ?
>>
>
> I tried O0/1/2 without luck.  I just checked though that they were
> actually being used in the verbose boost output and turns out boost is
> forcing a O3 as the last O value in the flags.  So there's a bug....
> I'll see if I can reasonably fix that  and retest.
>

Looks like there is a bjam property which can be set.  Is this
something we want tweak?  I did a quick test after applying the patch
below and the build was successful.

--- a/package/boost/boost.mk
+++ b/package/boost/boost.mk
@@ -90,6 +90,7 @@ endif

 BOOST_OPTS += toolset=gcc \
             threading=multi \
+             optimization=off \
             abi=$(BOOST_ABI) \
             variant=$(if $(BR2_ENABLE_DEBUG),debug,release)


I updated per the patch below (O3) and the build failed.  So it does
look like disabling optimization works around the problem.  What's
your thought going forward?  I can retest the other two packages to
see if no optimization fixes them too?

--- a/package/boost/boost.mk
+++ b/package/boost/boost.mk
@@ -90,6 +90,7 @@ endif

 BOOST_OPTS += toolset=gcc \
             threading=multi \
+             optimization=speed \
             abi=$(BOOST_ABI) \
             variant=$(if $(BR2_ENABLE_DEBUG),debug,release)


Matt

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Thomas Petazzoni]

Hello,

On Mon, 28 May 2018 15:05:44 -0500, Matthew Weber wrote:

> > I tried O0/1/2 without luck.  I just checked though that they were
> > actually being used in the verbose boost output and turns out boost is
> > forcing a O3 as the last O value in the flags.  So there's a bug....
> > I'll see if I can reasonably fix that  and retest.
> >  
> 
> Looks like there is a bjam property which can be set.  Is this
> something we want tweak?  I did a quick test after applying the patch
> below and the build was successful.
> 
> --- a/package/boost/boost.mk
> +++ b/package/boost/boost.mk
> @@ -90,6 +90,7 @@ endif
> 
>  BOOST_OPTS += toolset=gcc \
>              threading=multi \
> +             optimization=off \
>              abi=$(BOOST_ABI) \
>              variant=$(if $(BR2_ENABLE_DEBUG),debug,release)
> 
> 
> I updated per the patch below (O3) and the build failed.  So it does
> look like disabling optimization works around the problem.  What's
> your thought going forward?  I can retest the other two packages to
> see if no optimization fixes them too?

Thanks for doing all those tests! Yes, it would be nice to retest if
the other packages can be built without optimizations. If that's the
case, we can simply disable optimizations for Microblaze for those few
packages. It's less annoying that having those additional dependencies
that we have to propagate to reverse dependencies.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Matthew Weber]

Thomas,

On Mon, May 28, 2018 at 3:41 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 28 May 2018 15:05:44 -0500, Matthew Weber wrote:
>
>> > I tried O0/1/2 without luck.  I just checked though that they were
>> > actually being used in the verbose boost output and turns out boost is
>> > forcing a O3 as the last O value in the flags.  So there's a bug....
>> > I'll see if I can reasonably fix that  and retest.
>> >
>>
>> Looks like there is a bjam property which can be set.  Is this
>> something we want tweak?  I did a quick test after applying the patch
>> below and the build was successful.
>>
>> --- a/package/boost/boost.mk
>> +++ b/package/boost/boost.mk
>> @@ -90,6 +90,7 @@ endif
>>
>>  BOOST_OPTS += toolset=gcc \
>>              threading=multi \
>> +             optimization=off \
>>              abi=$(BOOST_ABI) \
>>              variant=$(if $(BR2_ENABLE_DEBUG),debug,release)
>>
>>
>> I updated per the patch below (O3) and the build failed.  So it does
>> look like disabling optimization works around the problem.  What's
>> your thought going forward?  I can retest the other two packages to
>> see if no optimization fixes them too?
>
> Thanks for doing all those tests! Yes, it would be nice to retest if
> the other packages can be built without optimizations. If that's the
> case, we can simply disable optimizations for Microblaze for those few
> packages. It's less annoying that having those additional dependencies
> that we have to propagate to reverse dependencies.
>

Looks like all 3 can build when optimization is set to 0 (off).
However none of them use the flag we provide and hardcode to either
O2/3 (I had to manually rework the packages to set the O0 for
testing).  Assuming this GCC bug patch is probably the way to go at
this point?

Is this something that would be resolved when/if we rework the gcc
wrapper and how we manage flags?

Matt

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Arnout Vandecappelle]

On 28-05-18 23:41, Matthew Weber wrote:
> Thomas,
> 
> On Mon, May 28, 2018 at 3:41 PM, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>> Hello,
>>
>> On Mon, 28 May 2018 15:05:44 -0500, Matthew Weber wrote:
>>
>>>> I tried O0/1/2 without luck.  I just checked though that they were
>>>> actually being used in the verbose boost output and turns out boost is
>>>> forcing a O3 as the last O value in the flags.  So there's a bug....
>>>> I'll see if I can reasonably fix that  and retest.
>>>>
>>>
>>> Looks like there is a bjam property which can be set.  Is this
>>> something we want tweak?  I did a quick test after applying the patch
>>> below and the build was successful.
>>>
>>> --- a/package/boost/boost.mk
>>> +++ b/package/boost/boost.mk
>>> @@ -90,6 +90,7 @@ endif
>>>
>>>  BOOST_OPTS += toolset=gcc \
>>>              threading=multi \
>>> +             optimization=off \
>>>              abi=$(BOOST_ABI) \
>>>              variant=$(if $(BR2_ENABLE_DEBUG),debug,release)
>>>
>>>
>>> I updated per the patch below (O3) and the build failed.  So it does
>>> look like disabling optimization works around the problem.  What's
>>> your thought going forward?  I can retest the other two packages to
>>> see if no optimization fixes them too?
>>
>> Thanks for doing all those tests! Yes, it would be nice to retest if
>> the other packages can be built without optimizations. If that's the
>> case, we can simply disable optimizations for Microblaze for those few
>> packages. It's less annoying that having those additional dependencies
>> that we have to propagate to reverse dependencies.
>>
> 
> Looks like all 3 can build when optimization is set to 0 (off).
> However none of them use the flag we provide and hardcode to either
> O2/3 (I had to manually rework the packages to set the O0 for
> testing).  Assuming this GCC bug patch is probably the way to go at
> this point?
> 
> Is this something that would be resolved when/if we rework the gcc
> wrapper and how we manage flags?

 I think that for optimisation (and debug, and ssp, ...) flags it should be
possible for packages to disable them. Some packages may not work at some
optimisation levels, or they need debug info for some reason, or ... I think
that if we put the optimisation flags inside the wrapper, it will be very hard
for packages to override them. In particular, I think there are some
combinations (e.g. '-Os -O2') that have a different effect than having an
optimisation option by itself. So putting the optimisation options inside the
wrapper may not be the right thing to do.

 Also, if a package explicitly passes some optimisation flag, like boost is
doing here, whatever we do in the wrapper is not going to have any effect
(because the externally passed options come after the wrapper options). So
putting it in the wrapper is definitely not a silver bullet.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v2] toolchain: GCC bug 85180

[Thomas Petazzoni]

Hello,

On Mon, 28 May 2018 10:35:10 -0500, Matt Weber wrote:
> Works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
> which is an issue where the Microblaze archtecture had code that
> caused a infinite recursion while optimizing in versions of GCC
> less then 8.x.  More BR discussion can be found on this thread.
> http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2018-04-25-td192721.html
> 
> Resolves:
> http://autobuild.buildroot.net/results/b42d68c66d8ea035845a28c5530ef0682fd95713 (boost)
> http://autobuild.buildroot.net/results/af976a4805fb8b3f0c17a8e3a1f901b2255caa0b (flare-engine)
> http://autobuild.buildroot.net/results/d20/d20700bd538ba1e9d45ab8a61ecbbba1a320ef38 (gst-ffmpeg)
> 
> CC: Romain Naour <romain.naour@gmail.com>
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> ---

Applied to master with some minor tweaks. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com