On 01/22/2018 05:38 PM, Hadrien Grasland wrote:
...that is, until you end up on a codebase which:
* Has -Werror hardcoded deep into its build system.
That doesn't make any sense. You can always override/amend CFLAGS/CXXFLAGS. There is no such thing as "deeply hardcoded".
* Relies on code which does not follow the C/++ standard to get compiled by accident.
Never seen that.
* Relies on undefined behaviour, or another codegen characteristic that is considered an unimportant detail by GCC's optimizer.
Never seen that.
* Uses compiler version detection macros which have not been adapted to the new GCC release.
That would speak of a very poor build system. Yet, I don't think I have run into such a problem.
* Causes an ICE in that specific release of GCC, which was introduced by accident in what was supposed to be a simple bugfix.
Very rare. So far I have only seen such problems on less common architectures and it was always a breeze to get these things fixed with upstream.
Relying on UB especially happens more often than one would think, and is basically the kernel of truth behind the old "-O3 breaks code" meme.
No matter which way one looks at it, compiler updates are unfortunately always a bit of a risky business from a Linux distribution maintainer's point of view.
Thanks, but I have helped with several gcc transitions in Debian. I never saw anything there as close as with Rust. The changes in gcc actually made sense to me, as I said, I was always able to address them with either very simple patches or by just disabling a certain warning. What about the fact that Rust only considers x86/x86_64 to be a tier 1 architecture? We have just recently seen with Spectre and Meltdown how bad it is to merely focus on x86. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org