In ("x86: extend SSE check to PCLMULQDQ, AES, and GFNI insns") I went
both a little too far and not quite far enough:
- GFNI insns also have AVX512 variants, which also shouldn't get
diagnosed,
- SSE4a insns should get diagnosed just like SSE4.x ones,
- SHA insns should get diagnosed just like PCLMULQDQ or AES ones.
The option framework documentation was speaking about a 'print -raw'
option, but this option does not exist.
This patch implements -raw-values option that tells to ignore the
active pretty printers when printing a value.
As we already have -raw-frame-arguments, I thought -raw-values
was more clear, in particular to differentiate
set print raw-values and set print raw-frame-arguments.
gdb/doc/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Command Options): Use -p and -pretty in the example,
as -r is ambiguous. Update the print - TAB TAB completion result.
(Data): Document new option -raw-values. Use -p and -pretty in the
example, as -r is ambiguous.
(Print Settings): Document set print raw values.
(Pretty-Printer Commands): Document interaction between enabled
pretty printers and -raw-values/-raw-frame-arguments.
gdb/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Document -raw-values option and the related setting commands.
* printcmd.c (print_command_parse_format): Do not set opts->raw off,
only set it on when /r is given.
* valprint.c (value_print_option_defs): New element raw-values.
* Makefile.in: Add the new file.
gdb/testsuite/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/options.exp: Add -raw-values in the print completion list.
* gdb.python/py-prettyprint.exp: Add tests for -raw-values.
This is
*cst = (data[0] << 24) + (data[1] << 16) + (data[2] << 8) + data[3];
data is unsigned char which promotes to int.
* h8300-dis.c (extract_immediate): Avoid signed overflow.
(bfd_h8_disassemble): Likewise.
In the following buf is an unsigned char array, so elements are
promoted to int before arithmetic operations.
if (dis_info.info->endian == BFD_ENDIAN_BIG)
while (n--)
val |= buf[n] << (n*8);
else
for (i = 0; i < n; i++)
val |= buf[i] << (i*8);
* csky-dis.c (csky_chars_to_number): Rewrite. Avoid signed
overflow when collecting bytes of a number.
This was the following in print_with_operands
case 4:
number
= buffer[2] + buffer[3] * 256 + buffer[4] * 65536
+ buffer[5] * 0x1000000;
and buffer[5] * 0x1000000 can indeed overflow. So to fix this we need
to use unsigned arithmetic where overflow semantics are specified.
But number is a long, and the expression is int which will be sign
extended to long. If we make the expression unsigned it will be zero
extended. So make number an int32_t and rearrange a little for some
of the places that need fixing.
* cris-dis.c (print_with_operands): Avoid signed integer
overflow when collecting bytes of a 32-bit integer.
This was:
unsigned long mask = SBM (instruction->match_bits);
with
#define SBM(offs) ((((1 << (32 - offs)) -1) << (offs)))
Well, there are a couple of problems. Firstly, the expression uses
int values (1 rather than 1u or 1ul) resulting in the ubsan error, and
secondly, a zero offs will result in a 32-bit shift which is undefined
if ints are only 32 bits.
* cr16-dis.c (EXTRACT, SBM): Rewrite.
(cr16_match_opcode): Delete duplicate bcond test.
This was the following in fmtconst_val, x is unsigned int.
x = SIGNEXTEND (x, constant_formats[cf].nbits);
Problem is, the SIGNEXTEND macro assumed its arg was a long and sign
extended by shifting left then shifting right, and didn't cast the
arg. So don't do the silly shift thing. It's not guaranteed to work
anyway according to the C standard. ">>" might do a logical shift
even if its args are signed.
* bfin-dis.c (HOST_LONG_WORD_SIZE, XFIELD): Delete.
(SIGNBIT): New.
(MASKBITS, SIGNEXTEND): Rewrite.
(fmtconst): Don't use ? expression now that SIGNEXTEND uses
unsigned arithmetic, instead assign result of SIGNEXTEND back
to x.
(fmtconst_val): Use 1u in shift expression.
When operand->bits is 32, the following results in UB.
value = (insn >> operand->shift) & ((1 << operand->bits) - 1);
* arc-dis.c (find_format_from_table): Use ull constant when
shifting by up to 32.
Assembling this to an object and trying to disassemble results in
objdump -d looping forever.
.inst 0x45205120
PR 25270
* aarch64-dis.c (aarch64_decode_variant_using_iclass): Return
false when field is zero for sve_size_tsz_bhs.
In Operand_soffsetx4_decode:
soffsetx4_0 = 0x4 + ((((int) offset_0 << 14) >> 14) << 2);
and other places.
Don't sign extend with shifts! This file also has many occurrences of
truncation via shifts, which aren't a problem due to using uint32, but
I dislike on principle enough to fix.
* xtensa-modules.c (Field_* functions): Don't mask using shifts.
(Operand_soffsetx4_decode, Operand_simm4_decode),
(Operand_simm8_decode, Operand_simm8x256_decode),
(Operand_simm12b_decode, Operand_label8_decode),
(Operand_label12_decode, Operand_soffset_decode),
(Operand_xt_wbr15_label_decode, Operand_xt_wbr18_label_decode): Don't
sign extend using shifts.
(Operand_immrx4_decode, Operand_uimm16x4_decode): Avoid UB in
constant.
Two places in epiphany_cgen_extract_operand, "value" is a long.
value = ((((value) << (1))) + (pc));
cpu/
* epiphany.cpu (f-simm8, f-simm24): Use multiply rather than
shift left to avoid UB on left shift of negative values.
opcodes/
* epiphany-ibld.c: Regenerate.
Here, since val is signed:
*valuep = (val << scale);
* cpu-ia64-opc.c (ext_imms_scaled): Avoid undefined left shift
of negative values by using unsigned vars.
I noticed that an example in the gdb.prompt documentation used the
wrong kind of quotes -- because it is code, it should use a plain
ASCII quotation mark. I also slightly shortened the sample text here,
so it would more clearly fit on a single line.
gdb/doc/ChangeLog
2019-12-10 Tom Tromey <tom@tromey.com>
* python.texi (gdb.prompt): Use correct quotes in example.
Shorten sample text.
Change-Id: I4153928c0d88001244ad410f3943c952a6ebfeb1
Add tests which check for accessibility of variables from within
various OpenMP parallel regions.
Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP
work on Fedora 30. The test has been annotated with setup_xfail and
setup_kfail statements so that there are no unexpected failures on any
of these platforms when using gcc. Better still, for my own testing
anyway, is that there are also no XPASSes or KPASSes either. So,
regardless of platform, when using gcc, and regardless of whether my
(not yet public) OpenMP work is used, seeing a FAIL indicates a real
problem.
Fedora 27 results:
# of expected passes 85
# of expected failures 65
(Note: I have not retested F27 since v1 of the patch; it's possible
that the numbers will be slightly different for v2.)
Fedora 28, 29, 30 results:
# of expected passes 131
# of expected failures 4
# of known failures 16
Fedora 30, 31 results w/ my OpenMP work:
# of expected passes 151
The above results all use gcc, either the system gcc or a development
gcc (when testing against my OpenMP work in GDB). I've also tested
with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31.
Fedora 31, clang:
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j
Fedora 31, icc:
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
For both clang and icc, it turns out that there are some problems with
the DWARF that these compilers generate. Of the two, icc does at
least nest the subprogram of the outlined function representing the
parallel region within the function that it's defined, but does not
handle inner scopes if they exist. clang places the subprogram for
the outlined function at the same level as the containing function, so
variables declared within the function aren't visible at all.
I could call setup_xfail to avoid FAILs for clang and icc also, but I don't
want to further complicate the test.
gdb/testsuite/ChangeLog:
* gdb.threads/omp-par-scope.c: New file.
* gdb/threads/omp-par-scope.exp: New file.
Change-Id: Icb9c991730d84ca7509380af817dfcc778e764ea
This commit adds the gdb_caching_proc, support_nested_function_tests,
to lib/gdb.exp. It tests to see whether or not the C compiler has
support for nested function calls.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (support_nested_function_tests): New proc.
Change-Id: Ic2c93bc4cc200e07e104a2398f89a9c0514bdc75
We only ever use one of the two overloads, so to avoid breaking -Werror
builds, supress the warning.
gdb/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/safe-strerror.c: Supress the unused function warning
for select_strerror_r.
Change-Id: I344869a382bb36fe181b5b2a31838d1d20f58169
To do that, this patch makes IPA compile safe-strerror as well. Because
it doesn't use Gnulib, it calls the Glibc version of strerror_r directly.
Consequently this patch also removes the configure checks for strerror.
gdb/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* gdbsupport/agent.c (gdb_connect_sync_socket): Call
safe_strerror instead of strerror.
* gdbsupport/common.m4: Don't check for strerror.
* gdbsupport/safe-strerror.c: Support both the glibc version
of strerror_r and the XSI version.
gdb/gdbserver/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Add safe-strerror.c to gdbreplay and IPA, and change
UNDO_GNULIB_CFLAGS to undo strerror_r instead of strerror.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Don't check for strerror.
* linux-i386-ipa.c (initialize_fast_tracepoint_trampoline_buffer):
Call safe_strerror instead of strerror.
* server.h (strerror): Remove this now-unnecessary declaration.
* tracepoint.c (init_named_socket): Call safe_strerror instead of
strerror.
(gdb_agent_helper_thread): Likewise.
* utils.c (perror_with_name): Likewise.
Change-Id: I74848f072dcde75cb55c435ef9398dc8f958cd73
This patch fixes .arch_extension behaviour.
Currently, context table for '.arch_extension' is only set while
"-march" processing, but it is not set while .arch processing,
so following code is rejected
.syntax unified
.thumb
.arch armv8.1-m.main
.arch_extension mve.fp
unless -march=armv8.1-m.main is given.
Committing on behalf of Vladimir Murzin
gas/ChangeLog:
2019-12-10 Vladimir Murzin <vladimir.murzin@arm.com>
* config/tc-arm.c (s_arm_arch): Set selected_ctx_ext_table.
* testsuite/gas/arm/mve-arch-ext.s: New.
* testsuite/gas/arm/mve-arch-ext.d: New.
Sometimes -- notably with unchecked unions -- the Ada "ptype" code
will print a "?" or "??" to indicate something unknown. The choice of
what was printed was somewhat arbitrary, and in one case, Ada would
print an empty string rather than "?".
This patch normalizes the Ada code to use "?" rather than an empty
string or "??". My reasoning here is that a single question mark is
enough to convey unknown-ness.
gdb/ChangeLog
2019-12-10 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices): Use a single "?".
(print_variant_part): Print "?" if the discriminant name
is not known.
gdb/testsuite/ChangeLog
2019-12-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/unchecked_union.exp: New file.
* gdb.ada/unchecked_union/pck.adb: New file.
* gdb.ada/unchecked_union/pck.ads: New file.
* gdb.ada/unchecked_union/unchecked_union.adb: New file.
* gdb-utils.exp (string_to_regexp): Also quote "?".
Change-Id: I3403040780a155ffa2c44c8e6a04ba86bc810e29
ppc-dis.c used a global struct whenever malloc failed to provide the
eight bytes of memory necessary for struct dis_private. Which is
quite ridiculous. If that malloc failed there is zero chance some
other malloc won't fail too.
* ppc-dis.c (private): Delete variable.
(get_powerpc_dialect): Don't segfault on NULL info->private_data.
(powerpc_init_dialect): Don't use global private.
The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.
This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.
gdb/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Fix scripted probe breakpoints.
* breakpoint.c (tracepoint_probe_breakpoint_ops): Move
declaration forward.
(breakpoint_ops_for_event_location_type)
(breakpoint_ops_for_event_location): Add function definitions.
(break_command_1, trace_command): Use
breakpoint_ops_for_event_location.
* breakpoint.h (breakpoint_ops_for_event_location): Add function
declarations.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use
breakpoint_ops_for_event_location.
* python/py-breakpoint.c (bppy_init): Use
breakpoint_ops_for_event_location.
gdb/testsuite/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Test scripted probe breakpoints.
* gdb.guile/scm-breakpoint.c (main): Add probe point.
* gdb.python/py-breakpoint.c (main): Likewise.
* gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe
specifier test.
* gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
Passing an lvalue argument to a function that takes an rvalue parameter
is not allowed per C++ rules. Consider this function:
int g (int &&x) { return x; }
Calling g as in
int i = 5;
int j = g (i);
is illegal. For instance, GCC 9.2.1 yields
~~~
test.cpp: In function ‘int main()’:
test.cpp:6:14: error: cannot bind rvalue reference of type ‘int&&’ to
lvalue of type ‘int’
6 | int j = g (i);
| ^
~~~
GDB currently allows this function call:
~~~
(gdb) print g(i)
$1 = 5
~~~
Fix this by ranking an lvalue argument incompatible with an rvalue
parameter. The behavior after this patch is:
~~~
(gdb) print g(i)
Cannot resolve function g to any overloaded instance
~~~
Tested with GCC 9.2.1.
gdb/ChangeLog:
2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdbtypes.c (rank_one_type): Return INCOMPATIBLE_TYPE_BADNESS
when ranking an lvalue argument for an rvalue parameter.
gdb/testsuite/ChangeLog:
2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.cc (g): New function that takes
an rvalue parameter.
* gdb.cp/rvalue-ref-overload.exp: Test calling it with an lvalue
parameter.
Change-Id: I4a6dfc7dac63efa1e3b9f8f391e4b736fbdccdc1
Extend the output pattern in mi-fortran-modules.exp to skip some
system modules that appear with versions of GFortran after 7.x.x.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-fortran-modules.exp: Add patterns to skip system
modules.
Change-Id: I64aaa395e554a32e8267ffa096faee53c19c0b9e
In some cases the Fortran stride information generated by GCC is wrong
with versions of GCC after 7.x.x. This commit adds kfails for the
tests in question with known bad versions of gcc.
The bug has been reported to GCC here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-type-striding.exp: KFAIL if we are using a
broken version of GCC.
Change-Id: Iaef08e5e2c87ab3d6983b88f749d40e01aea2bc6
The gdb.fortran/info-modules.exp and gdb.fortran/info-types.exp tests
are failing on versions of gfortran after 7.3 due to the inclusion of
extra "system" modules and type that were not being matched by the
current test patterns.
Rather than building increasingly complex patterns that would always
be at risk of breaking with future versions of GCC I have instead
added a new library that parses the output of the following commands:
info types
info variables
info functions
info modules
info module functions
info module variables
into a data structure, the test can than run checks against the
contents of this data structure.
The benefit is that we can simply ignore extra results that we don't
care about.
There is a small risk that a bug in GDB might allow us to start
reporting incorrect results in such a way that the new library will
not spot the error. However, I have tried to mitigate this risk by
adding extra procedures into the test library (see check_no_entry) and
we can add more in future if we wanted to be even more defensive.
I tested this test file with gFortran 7.3.1, 8.3.0, and 9.2.0, I now
see 100% pass in all cases.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Rewrite to make use of new
sym-info-cmds library.
* gdb.fortran/info-types.exp: Likewise.
* lib/sym-info-cmds.exp: New file.
Change-Id: Iff81624f51b5afb6c95393932f3d94472d7c2970
This should be the type of startup_with_shell, whose type was changed
from int to bool at commit 80fd28264.
This fixes the build on macOS:
CXX darwin-nat.o
In file included from ../../gdb/darwin-nat.c:22:
In file included from ../../gdb/top.h:25:
In file included from ../../gdb/value.h:23:
In file included from ../../gdb/frame.h:72:
In file included from ../../gdb/language.h:26:
In file included from ../../gdb/symtab.h:33:
../../gdb/gdbsupport/gdb_optional.h:155:19: error: no matching constructor for initialization of 'scoped_restore_tmpl<int>'
new (&m_item) T (std::forward<Args>(args)...);
^ ~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/darwin-nat.c:1995:31: note: in instantiation of function template specialization 'gdb::optional<scoped_restore_tmpl<int> >::emplace<bool *, int>' requested here
restore_startup_with_shell.emplace (&startup_with_shell, 0);
^
../../gdb/gdbsupport/scoped_restore.h:69:3: note: candidate constructor template not viable: no known conversion from 'bool *' to 'int *' for 1st argument
scoped_restore_tmpl (T *var, T2 value)
^
../../gdb/gdbsupport/scoped_restore.h:57:3: note: candidate constructor not viable: requires single argument 'var', but 2 arguments were provided
scoped_restore_tmpl (T *var)
^
../../gdb/gdbsupport/scoped_restore.h:76:3: note: candidate constructor not viable: requires single argument 'other', but 2 arguments were provided
scoped_restore_tmpl (const scoped_restore_tmpl<T> &other)
^
1 error generated.
gdb/ChangeLog
2019-12-08 Wataru Ashihara <wataash@wataash.com>
* darwin-nat.c (darwin_nat_target::create_inferior): Fix
template argument for scoped_restore_tmpl from bool to int.
Change-Id: Ia0202efd34dbce69b6af5d035fa55ed89215138a
This is an alias of "qword ptr", commonly used with MMX insns.
At this occasion also test (alongside the newly supported "mmword")
- "zmmword" used as expression,
- PADDB with "oword ptr" (aliasing "xmmword ptr").
Commit dc2be329b9 ("i386: Only check suffix in instruction mnemonic")
broke rejecting of these for floating point insns. Fix this by setting
the "byte" operand attribute, which will now (again) cause an error.
Furthermore the diagnostic for the "far ptr" case in general and for the
"near ptr" case in the non-float cases became "invalid instruction
suffix" instead of the intended "operand size mismatch". Fix this by
also setting the "tbyte" operand attribute (no insn template accepts
both byte and tbyte operands).
There are extremely few insns accepting "tbyte ptr" operand, so the
"tbyte" operand flag checking done by match_operand_size() is already
sufficient; the setting of the suffix has become meaningless anyway
with dc2be329b9 ("i386: Only check suffix in instruction mnemonic").
Fold the code with that setting the "byte" operand flag to force an
error (no insn at all accepts both "byte ptr" and tbyte ptr" operands,
except for AnySize ones where the two (conflicting) recorded types
don't matter (operand_size_match() doesn't call match_operand_size() in
this case).
