On 11/14/2018 02:39 AM, Alexander Monakov wrote:
On Tue, 13 Nov 2018, Martin Sebor wrote:
In PR 88000 the reporter expects to be able to use an explicit
register local variable in a context where it isn't supported
i.e., for something other than an input or output of an asm
statement: namely to pass it as argument to a user-defined
function. GCC emits unexpected object code in this case which
the reporter thought was a GCC bug.
I appreciate warnings for misuse of extensions in general, but in
this particular case I think GCC's behavior is misdesigned, so
instead of enshrining a bad engineering choice in a warning and
in the manual, I'd rather see GCC implement the extension sanely.
Merely changing a normal auto variable to a register asm variable
should not invalidate the program. As the manual says, it should
amount to providing a hint to the register allocator, at most.
Have a look at PR 87984, where code is miscompiled despite following
the documentation to the letter. This is because we lower accesses to
register variables when transitioning from GIMPLE to RTL incorrectly.
Fixing that should make the warning unnecessary. I hope I can work on
that before stage 4.
I think LLVM is doing the right thing there, and so should we.
That would indeed be preferable but it's not something I expect
to have the cycles to work on. I put the patch together only
because it seemed like an easy way to help keep users from
shooting themselves in the foot (to borrow the phrase from
the comment in PR 88000).
If there's consensus that the general use case of passing hard
registers to functions should be supported then I suggest to
acknowledge PR 88000 as a bug. We can discuss whether it's
possible and worthwhile to warn on the unsupported subset of
the use cases. In any case, I think the least we can for now
is to clarify in the manual what that supported subset is,
since as I (and others) read it, passing hard registers to
functions is not.
Martin
