https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #13 from Rich Felker <bugdal at aerifal dot cx> --- > That does not look at types. It complains that "x" lives in memory, > while the constraint requires a register (a floating point register). That does not sound accurate. An (in this case lvalue since it's an output too, but for input0-only, non-lvalues as well) expression does not "live in memory"; that is not the problem here. Unless the address has leaked outside of the current scope of transformations, objects may not live in memory at all, only in registers, or a mix of registers and temporary spills, etc. The asm constraints guide the compiler's choices of where to put it (and may *force* it to be moved back/forth, e.g. if you use an "m" constraint for a variable that could otherwise be kept in a register, or a register constraint for one that otherwise would only be accessed via memory), not the other way around. The problem here is that GCC has no way to bind an integer expression to a floating point register. It *is* a matter of type. There are probably subtleties to this that I don't understand, but it's not about "living in memory". > No, they are not. The constraints are an implementation detail. And > they *have* to be, or we could never again improve anything. If they are in the documentation, they're not implementation details. They're interfaces necessary to be able to use inline asm, which is a documented and important feature of the "GNU C" language. In particular, "ws" is documented for the purpose we're using it for: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Machine-Constraints.html > Unfortunately we currently document most of them in the user manual as > well. It's on my list of things to change, for GCC 10. Most targets > still have this problem, fwiw. If you intend to remove documented functionality on an even larger scale, that is a breaking change, and one which I will (loudly) oppose. If there are legitimate reasons for such changes to be made internally, a layer should be put in place so that code using the constraints continues to work without imposing on the backend implementation. > What I am talking about is that people rely on implementation details > no matter what we do, and then prevent us from changing them. That may be true, but it's not related to this bug report and I have not seen evidence of it happening. I'll gladly fix it if we're doing that anywhere.
