RFR: 8276563: Undefined Behaviour in class Assembler [v3]

[Andrew Haley]

On Sat, 13 Nov 2021 09:46:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/register_aarch64.hpp line 63:
>> 
>>> 61:   // accessors
>>> 62:   int encoding() const             { assert(is_valid(), "invalid register"); return encoding_nocheck(); }
>>> 63:   bool is_valid() const            { return this >= first() && this < invalid(); }
>> 
>> is_valid() now returns true for ZR, SP. Was this intended? This affects other functions too, e.g. `RegisterImpl::name()`.
>
> I think so, yes. SP and ZR are valid registers. `is_valid()` should only return `false` for `noreg`.

Done. I decided to leave this as it is. `is_valid()` now returns true for only r0 ... r31.

>> src/hotspot/cpu/aarch64/register_aarch64.hpp line 64:
>> 
>>> 62:   int encoding() const             { assert(is_valid(), "invalid register"); return encoding_nocheck(); }
>>> 63:   bool is_valid() const            { return this >= first() && this < invalid(); }
>>> 64:   bool has_byte_register() const   { return is_valid(); }
>> 
>> Same here, semantics changed to include 32 and 33
>
> I guess it would be "safer" to go back to excluding SP and ZR, but it was never intentional to exclude them. I'll go through all the uses of is_valid() to see which is best.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6280