diff options
| author | Jan Beulich <jbeulich@suse.com> | 2022-05-27 08:46:29 +0200 |
|---|---|---|
| committer | Jan Beulich <jbeulich@suse.com> | 2022-05-27 08:46:29 +0200 |
| commit | a5748e0d8c50913e3c84a71e7e72faf0f4637021 (patch) | |
| tree | 77bce69a458a65e31ffd4eaa41eb8316f560260d /binutils | |
| parent | 811f61d4c453934b765c73bde78fc29ea22c0c7d (diff) | |
| download | binutils-a5748e0d8c50913e3c84a71e7e72faf0f4637021.zip binutils-a5748e0d8c50913e3c84a71e7e72faf0f4637021.tar.gz binutils-a5748e0d8c50913e3c84a71e7e72faf0f4637021.tar.bz2 | |
x86/Intel: allow MASM representation of embedded broadcast
MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Accept these forms
alongside the original (now legacy) ones.
Acceptance of the original {1to<n>} operand suffix is retained both for
backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector
conversions with shrinking element sizes. I have no insight (yet) into
how MASM expects those to be disambiguated.
Adjust some, but not all of the testcases.
Diffstat (limited to 'binutils')
0 files changed, 0 insertions, 0 deletions