https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585
--- Comment #11 from Harald van Dijk <harald at gigawatt dot nl> --- (In reply to Segher Boessenkool from comment #10) > 1) It wasn't defined behaviour before, so nothing changed in that regard. > Many changes changes behaviour on invalid code. Not all invalid code gets > a diagnostic. That doesn't mean it's acceptable to change how that's handled in a minor release. The whole concept of a release series doesn't make sense if you take that route. Take a look at how signed integer overflow was handled, for instance. We all know that's invalid and has always been invalid, but the change to enable -fstrict-overflow at -O2 was saved for the next major release and clearly documented in the GCC 4.2 Changes page <https://gcc.gnu.org/gcc-4.2/changes.html>. A release series should mean that it is safe for distros to upgrade within the release series. Right now, it's not. > 2) Incompatible clang behaviour on GNU C extensions is not GCC's fault. There was no incompatible clang behaviour, so this comment does not make sense. clang accepted the code with a warning where GCC accepted it without a warning, but it behaved the same in both compilers, until GCC 8.3. > 3) I've heard of only one program where this change showed this problem (Qt), > and it has been fixed there long ago. So silly me thought that was the end > of it. Long ago? It definitely breaks last years' releases, though I have not tested with the most recent versions. Even if it didn't, distros are likely to be stuck with supporting Qt 4.x for a while. When they bump to GCC 9, they know they have to deal with breakage and patch code, but when they bump to GCC 8.3, this is a nasty surprise. > And then my backport was approved, too. Your backport was approved after a highly misleading message on the mailing list. You wrote: > I'd like to backport the "asm inline" series to 8 branch and 7 branch. > The patches are identical to trunk, except I added a patch 8/8 that > makes these branches not error on code it only warned on before (that > is, C code that uses restrict or const as asm qualifier). Technically, this is 100% true. What's missing from this is that it *does* error on code it previously accepted *without* a warning. Whether it would have been approved if you had included that bit in your e-mail is something we'll never know. > 4) Yeah, a more specific diagnostic might be nice (not all qualifiers are > asm qualifiers). This should go to trunk first then, of course. Given that any changes to re-accept the code would be limited to GCC 8 only, that probably shouldn't go on trunk. But if a change on trunk to give a decent diagnostic can be trivially tweaked to allow the code on GCC 8 again, with a warning, then great! I'll be happy to help test anything that can be backported to GCC 8 to allow this again.
