Potential downsides of compiling with gcc9 and latest binutils?

In the advanced image building options there are 4 options to set the GCC version (defaults to 7, 8&9 available), and 3 options for binutils, which defaults to the middle version.

I've set them both to the newest version (GCC9 and binutils 2.32), and compiled with my normal configuration. Apart from having to de-select USBIP, which failed to compile on latest master from yesterday, the build went well, and is now running on an ath79 test device.

  • Are there any known downsides of using the newer versions?
  • Is the build failure of USB-IP related? (currently building other gcc9 images, so can't try GCC7+usbip for a few more hours) (Note: I also built with -O2; that should always be "safe", no?)
  • If there are no known "big problems", why aren't newest GCC and binutils the default choices?

You can check/search bugs.openwrt.org for compiler version specific bugs.
The main "issue" would be that i suspect most devs/maintainers just go with the default settings for there testrun's and dev. environment. I also think the buildbots do the same, so any problem is missed by simply having done no tests on the none default versions.

I guess that's similar to many distros, adapting a new compiler takes time and often you have to ask the question the other way around. So What real world advantages does a new compiler version brings and why would you want to switch from a stable, tested version.?

In general i would stick with the default compiler, unless you have the need for a specific performance, size improvement by switching. Keep in mind that after switching the compiler, reporting bugs can be problematic, since you would have to reproduce some bug's with the default compiler, just to make sure its not compiler related.

4 Likes

My reasoning here was: "Newer compiler -> Smarter Compiler -> Better optimizations" (More "security/stableness" being a nice side-effect).

(Also, at the beginning, I thought, that for some Debian Buster related reason the old GCC7 was picked by default)

Specifically, I'm doing this to see, if the ipq40xx Gl.Inet B1300 then gets faster. (Very bad ping times at the moment (triple of other (older) devices in same RSN-IBSS)).

In general, I agree. "Well-trodden-path 'n' all"

Well, somebody took the time to integrate GCC8 and GCC9 support. Do you happen to know, if it was for a specific target? Is there a roadmap containing GCC{8,9}, like GCC8_for_20.06, then GCC9_for_22.06, or somesuch?

Same for the binutils?

Huh...?

Are you saying that you believe - by compiling the firmware with a different GCC version, that the resulting firmware will perform better when flashed onto the device?

Well, I'm not expecting large gains, but just attempting to dot all the "i"s, and cross all the "t"s. The thinking was: if "terrible" gets better by 10%, that'll already be around 0.15ms won.

1 Like

In general new GCC versions sometimes tend to miscompile code, for example at some point in the past, some new GCC major release miscompiled hostapd, opening potential security vulnerabilities on MIPS.

Its usually no issue to port/use new GCC on mainstream architectures like x86 or arm, but for less common targets, scrutiny is advised

2 Likes

Jow, +1 for this info. Just what I wanted to hear/know. Well, not "that" precisely, but information of this type.

I use a lot of MIPS here, which I assumed to be a "Mainstream" arch, but your first paragraph now gives me pause, especially with the enumeration in the second paragraph lacking "MIPS".

And GCC8 was never considered mature/good enough, and is being skipped? Or what are the future toolchain roadmap plans?

Until just ~2-3 weeks ago, gcc-9 was ridden with ICEs when compiling 32 bit/ i686 kernels (which is barely an exotic arch, nor an exotic codebase)…

New toolchain components (gcc and binutils in particular) just need a little time to mature, for the big bugs to be fleshed out.