Fedora 26 Looks At Updating Its CFLAGS / CXXFLAGS

[Mystro256]

`-Werror=<x>` is only a harder version of the `-W<x>`. I meant you were compiling without `-Wall` and had errors in your code, which only surfaced when a distro increased their errors to a 20-year old standards. You should seriously consider getting your code compiling with `-Wall` without any warnings raised. `-Werror` is just means to that end.

See my previous comment:

I've been trying to work with upstream to fix the colossal amount of compile time warnings it produces, so it's not a surprise that it happened to break when Werror flags were enabled.

I just didn't realize there was implicit-function-declaration warnings in there, as it was polluted with dereferencing type-punned pointer warnings, type warnings, unused variable warnings, style warnings, etc. Some of which are a little complicated to fix due to how the code is designed.

[ldo17]

Fewer and fewer Atom chips around?

So much for mighty Intel’s attempt to take on puny ARM...

[smitty3268]

Fewer and fewer Atom chips around?

So much for mighty Intel’s attempt to take on puny ARM...

Bay Trail/Braswell still exist, they're just 64 bit now. 32-bit Atom chips are going away.

[Azrael5]

x86_x64 is not pure x64?

[indepe]

Is "-O3" and LTO already in there?

[smitty3268]

x86_x64 is not pure x64?

x86-64 allows natively running x86 code in 32-bit mode, so it's not "pure" 64 bit only architecture.

It's what allowed the backwards compatibility with old 32 bit versions of windows and proprietary software.

That's the same as what people refer to as x64, AMD64, or EMT-64, though. It's different from a "pure" 64bit architecture like IA-64 which did not provide backwards compatibility (it was used in Itanium processors)

[ldo17]

x86-64 allows natively running x86 code in 32-bit mode, so it's not "pure" 64 bit only architecture.

By the same token, the 32-bit x86 processors allowed running 16-bit code written for 80286 and 8086/8088, so therefore they were not a “pure” 32-bit-only architecture?

[Zan Lynx]

Is "-O3" and LTO already in there?

LTO should probably be left up to the package authors. It's amazing how much stuff can break because the original authors figured that the compiler wouldn't optimize across file boundaries.

GCC's LTO is also still a little buggy in my experience. Lots of "fun" when it tries to devirtualize and inline C++ functions that actually do end up getting called virtually.

"I'm calling virtual function slot #4!"
"It isn't here."
"What do you mean it isn't here, there's a slot for it and everything."
"I didn't think anyone needed it."

I still haven't figured out how to produce a reduced test case for the bug report. But it's definitely a bug. Something about templated classes with virtual overrides and an out-of-view template instantiation.

[indepe]

LTO should probably be left up to the package authors. It's amazing how much stuff can break because the original authors figured that the compiler wouldn't optimize across file boundaries.

It's surely not as easy as it sounds, but that doesn't mean it is not easy.

As things stand, authors probably continue to assume that there is no optimization across files. It seems there are guidelines for these things, that authors are asked to follow, but no such guideline for LTO.

GCC's LTO is also still a little buggy in my experience. Lots of "fun" when it tries to devirtualize and inline C++ functions that actually do end up getting called virtually.

"I'm calling virtual function slot #4!"
"It isn't here."
"What do you mean it isn't here, there's a slot for it and everything."
"I didn't think anyone needed it."

I still haven't figured out how to produce a reduced test case for the bug report. But it's definitely a bug. Something about templated classes with virtual overrides and an out-of-view template instantiation.

OK, but since when are operating systems held up by a single bug? Maybe as long as it is just you, it will take a while for that bug to get fixed, but if distros start to use LTO in a larger way, something like that should get fixed quickly. LTO doesn't strike me as something that can't be made to work as a standard.

[Zan Lynx]

OK, but since when are operating systems held up by a single bug? Maybe as long as it is just you, it will take a while for that bug to get fixed, but if distros start to use LTO in a larger way, something like that should get fixed quickly. LTO doesn't strike me as something that can't be made to work as a standard.

I didn't mean to imply that bug was holding up all of Fedora. Just an example of where GCC still has a few issues. That particular one isn't even a LTO bug exactly, just seems to happen when GCC gets a chance to optimize a big pile of code. It does the same thing when I append all the code into one big CPP file. Like I said, producing a reduced test case has been really hard.

And yes, LTO works pretty well for most stuff. Microsoft's compiler uses it by default too. So programs like Firefox and most anything ever ported to Windows have already dealt with most of the odd problems.

I expect it will be a good idea by Fedora 28.