toolchain: GCC bug 85180

PATCH Superseded Matt Weber 3 participants 8 messages May 28, 2018 – May 30, 2018

Share & tools

Matt Weber

author

2018-05-28 15:35 UTC #0 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

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 <[email protected]>

Signed-off-by Matthew Weber <[email protected]>

---

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(+)

package/boost/Config.in +4 -0

index 0755d9c..ec0e19c 100644
@@ -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

package/flare-engine/Config.in +4 -0

index cdcb018..e299a6b 100644
@@ -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

package/gstreamer/gst-ffmpeg/Config.in +4 -0

index 32bfdd5..1e95d01 100644
@@ -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

toolchain/Config.in +5 -0

index 2479a65..61424ec 100644
@@ -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/

Signature · 1 line

1.9.1

Thomas Petazzoni

2018-05-28 19:29 UTC #1 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

Hello,

Quoted 6 lines · 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

Quoted 7 lines

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 <[email protected]>
Signed-off-by Matthew Weber <[email protected]>

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

Signature · 3 lines

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

Matthew Weber

author

2018-05-28 19:50 UTC #2 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

Thomas,

Quoted 15 lines · Thomas Petazzoni

Hello,
Quoted 11 lines · 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)

Quoted 6 lines

Quoted 2 lines
CC Romain Naour <[email protected]>
Signed-off-by Matthew Weber <[email protected]>
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.

Quoted 3 lines

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

Matthew Weber

author

2018-05-28 20:05 UTC #3 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

Thomas,

Quoted 30 lines · Matthew Weber

Thomas,
Quoted 15 lines · Thomas Petazzoni
Hello,
Quoted 11 lines · 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)
Quoted 6 lines
Quoted 2 lines
CC Romain Naour <[email protected]>
Signed-off-by Matthew Weber <[email protected]>
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.
Quoted 1 line

Quoted 8 lines

Quoted 2 lines
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.

package/boost/boost.mk +1 -0

@@ -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?

package/boost/boost.mk +1 -0

@@ -90,6 +90,7 @@ endif
 
 BOOST_OPTS += toolset=gcc \
             threading=multi \
+             optimization=speed \
             abi=$(BOOST_ABI) \
             variant=$(if $(BR2_ENABLE_DEBUG),debug,release)

Matt

Thomas Petazzoni

2018-05-28 20:41 UTC #4 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

Hello,

Quoted 21 lines · Matthew Weber

Quoted 5 lines
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.
package/boost/boost.mk +1 -0
@@ -90,6 +90,7 @@ endif
 
 BOOST_OPTS += toolset=gcc \
             threading=multi \
+             optimization=off \
             abi=$(BOOST_ABI) \
             variant=$(if $(BR2_ENABLE_DEBUG),debug,release)
 

Quoted 4 lines

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

Signature · 3 lines

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

Matthew Weber

author

2018-05-28 21:41 UTC #5 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

Thomas,

Quoted 25 lines · Thomas Petazzoni

Hello,
Quoted 21 lines · Matthew Weber
Quoted 5 lines
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.
package/boost/boost.mk +1 -0
@@ -90,6 +90,7 @@ endif
 
 BOOST_OPTS += toolset=gcc \
             threading=multi \
+             optimization=off \
             abi=$(BOOST_ABI) \
             variant=$(if $(BR2_ENABLE_DEBUG),debug,release)
 

Quoted 11 lines

Quoted 4 lines
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

Arnout Vandecappelle

2018-05-30 21:07 UTC #6 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

Quoted 41 lines · Matthew Weber

Thomas,
Quoted 25 lines · Thomas Petazzoni
Hello,
Quoted 21 lines · Matthew Weber
Quoted 5 lines
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.
package/boost/boost.mk +1 -0
@@ -90,6 +90,7 @@ endif
 
 BOOST_OPTS += toolset=gcc \
             threading=multi \
+             optimization=off \
             abi=$(BOOST_ABI) \
             variant=$(if $(BR2_ENABLE_DEBUG),debug,release)
 
Quoted 11 lines
Quoted 4 lines
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.

Quoted 8 lines

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

Signature · 6 lines

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

Thomas Petazzoni

Applied

2018-05-30 21:23 UTC #7 lore raw

PATCH v2 1/1 toolchain: GCC bug 85180

In reply to Matt Weber

Hello,

Quoted 6 lines · 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

Quoted 8 lines

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 <[email protected]>
Signed-off-by Matthew Weber <[email protected]>
---

Applied to master with some minor tweaks. Thanks!

Thomas

Signature · 3 lines

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