https://bugs.kde.org/show_bug.cgi?id=385411
--- Comment #15 from Andreas Arnez <ar...@linux.ibm.com> ---
(In reply to Julian Seward from comment #12)
> (In reply to Andreas Arnez from comment #10)
> [...]
> + unsigned int v2 : 4;
> etc
>
> For new structs like this, I'd prefer you use the house type "UInt" rather
> than "unsigned int".
Sure, I can change this. Just note that there are many such bit fields in the
s390-specific code already, and they generally seem to be declared as "unsigned
int". This particularly applies to the code surrounding the added structs,
which means that their different style will stick out. Or should we better
create a separate patch for changing all such occurrences in the s390-specific
code at once?
> +/* Check if "Single-Element-Control" bit is set.
> s/if/if the
OK.
> +static const HChar *
> +s390_irgen_VCDG(UChar v1, UChar v2, UChar m3, UChar m4, UChar m5)
> +{
> + vassert(m3 == 3);
> (and the same assertion in various functions below). The assertion
> really checks that there is some logic error in the s390 front end,
> right? In particular you're sure that it won't fail even in the
> case of unknown/undecodable instructions?
No. I stumbled upon that as well, but honestly didn't pay much attention to
it. Unfortunately the current code structure in guest_s390_toIR.c doesn't
provide a clean way of reporting a decoding error up through the call chain.
See my patch below for a possible solution.
> @@ -19357,6 +20039,18 @@ s390_decode_6byte_and_irgen(const UChar *bytes)
> unsigned int rxb : 4;
> unsigned int op2 : 8;
> } VRR;
> + struct {
> + unsigned int op1 : 8;
>
> Same comment as above re UInt.
The same as above applies.
--
You are receiving this mail because:
You are watching all bug changes.
