https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #24 from Rich Felker <bugdal at aerifal dot cx> --- > Sure, and I'll do that, *if there are users*, *after they fix their stuff*. Nothing is broken on our side here. We are using the documented functionality from gcc 9 going all the way back to whatever version first added this stuff. > I will not add back all constraints I removed. I *cannot* add back many of > those constraints, not with similar semantics anyway. > > Oh, and there were 24 I removed for 10, if I count correctly. All were > internal. That they were documented was a bug; How many others were actually-internal vs having this ridiculous excuse of "it was a bug that we documented it so we can retroactively blame programmers for using it rather than taking responsibility for the contract we documented"? Are any of the "*cannot* add back" ones things that were documented? If not, then you can add back all the ones that were documented with no harm done to anything. If there really are technical reasons that some of the ones removed are difficult to recreate, please say so. I would still strongly disagree with the choice to make such a regression, but at least it would have some reasonable motivation rather than the only motivation I've seen so far, which seems to be your desire to break things on a whim. > that one was actually used > by any program was unexpected (and it took literally half a year before this > was found out, or reported here at least). At least "ws" and "ww" are used, for fmax, fmaxf, fmin, and fminf. The reason it was not found for "literally half a year" is because the regression is not present in any release. Users generally do not use unstable GCC; my understanding is that it's not recommended to do so. > The point is that we will never get to a good state if we cannot fix > up any historical mistakes. That's an extreme exaggeration. There is nothing holding back a "good state" about having two aliases for "wa" to preserve documented historical behavior.
