GCC 12.1 Released

Posted May 6, 2022 21:45 UTC (Fri) by JoeBuck (guest, #2330)
In reply to: GCC 12.1 Released by wtarreau
Parent article: GCC 12.1 Released

The usual pattern is that the .1 release has cool new features and some new bugs, and the .2 release, which usually arrives about a month later, fixes most of the new bugs. So if you have quality concerns, the way to address them is to test promptly and submit bug reports.

to post comments

GCC 12.1 Released

Posted May 7, 2022 4:21 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (3 responses)

> So if you have quality concerns, the way to address them is to test promptly and submit bug reports.

Sure, but the concern is more, as usual, about breakage that is not considered as a bug but as an extended lecture of the spec that "allows us to do that so fix your program now even if it worked fine for 30 years on all compilers that way".

GCC 12.1 Released

Posted May 8, 2022 22:06 UTC (Sun) by ballombe (subscriber, #9523) [Link] (2 responses)

The opposite happened to me. The bug was not fixed because my code "interpreted the standard too rigidly..."

GCC 12.1 Released

Posted May 8, 2022 23:45 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

I remember reading in the comments of an otherwise-unrelated GCC bug[1] that ISO C says memcpy() is permitted to clobber errno, and that therefore gcc is technically required to either prove that errno is not used by the application code, or to emit extra instructions to save and restore the variable. The reaction from the gcc developers to this revelation could be paraphrased as "haha, no." Which isn't a terribly surprising response when you consider just how liberally gcc emits memcpy calls, but I found it amusing. So yes, they will deviate from the standard in cases where the standard is ridiculous or otherwise problematic.

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

GCC 12.1 Released

Posted May 9, 2022 0:47 UTC (Mon) by hvd (guest, #128680) [Link]

There is no requirement on compilers to support arbitrary libc implementations. libc and the compiler work together, either may depend on internals of the other to make the combined product conform to the relevant standards. For instance, glibc relies on the compiler to define __STRICT_ANSI__ when invoked in standards-conforming mode. The C standard says nothing about this macro beyond that it's in the namespace that's reserved for any use by the implementation and compilers are not required to define this macro, but that is not an issue, glibc is for use with compilers that do define it. If some other compiler, say, pcc, doesn't define it, fine, that just means pcc+glibc is not standards-conforming, but that's not a bug in either pcc or glibc, that's a problem for whoever decided to combine those two. It works the other way around as well. The compiler relies on memcpy to not set errno. The C standard does not guarantee this and implementations are allowed to set it, but GCC is for use with libc implementations that don't set it. If some hypothetical elibc does make memcpy set errno, that just means the combination of GCC+elibc is non-conforming, but that's not a bug in either GCC or elibc, that's a problem for whoever decided to combine those two.