public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [PATCH v2 00/17] gas: scrubber adjustments
@ 2024-07-12 12:51 Jan Beulich
  2024-07-12 12:56 ` [PATCH v2 01/17] x86: accept whitespace inside curly braces Jan Beulich
                   ` (19 more replies)
  0 siblings, 20 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 12:51 UTC (permalink / raw)
  To: Binutils; +Cc: Anthony Green, Alan Modra

The end goal is to finally deal with long standing issues in, in
particular, macro handling (see e.g. b3446f947bd1 ["gas: retain
whitespace between strings"]). That's the final patch. I've come
across various other issues though, which some of the earlier
patches aim at addressing. Imo those are (in principle, subject to
feedback of course) fine to go in for 2.43. Whereas I'd prefer the
final change to go in relatively early in a release cycle, to allow
time to deal with real or perceived regressions (see patches 07-12
for examples thereof).

One of the issues I'm facing in dealing with target specific
adjustments is that there are 5 gas targets which don't even have a
testsuite subdir:
- m32c (no maintainer)
- moxie
- ns32k (no maintainer)
- spu
- tic30 (no maintainer)
How is one supposed to have even the slightest idea whether a common
code change breaks such a target (Cc-ing the two maintainers of the
named targets which have one)? I'm already worried enough by targets
having only a pretty "slim" set of test cases. In any event, target
specific changes made in that final patch don't go much beyond what is
needed to have the testsuite pass. I'm pretty sure further changes are
going to be needed in perhaps many places; while I'll try to deal with
those as they're being pointed out, I think target maintainers are in
a better position to change what needs changing, as they ought to have
a better idea than me where whitespace may occur and hence need
skipping.

Doing better at skipping whitespace is, to some degree at least, also
a prereq for -f (or its equivalent #NO_APP at the start of a file) to
be reliable to use. It is probably for a reason that gcc currently
doesn't use this for most targets.

Compared to v1 this is now passing the testsuite for a wide range of
targets, thanks to various new patches and a number of target specific
changes in the final one (the Arm64 testsuite adjustments in
particular may already be insufficient again, though; I'll keep
re-basing them). All patches individually detail what has changed, if
anything.

There may be a contextual (but no functional) dependency on "x86: undo
'{' being a symbol-start character" submitted earlier today.

01: x86: accept whitespace inside curly braces
02: drop scrubber state -2
03: pre-init the scrubber's lex[]
04: re-work tic6x scrubber special case
05: consistently drop trailing whitespace when scrubbing
06: adjust impossible/bogus M68K/MRI special case when scrubbing
07: Arm: correct macro use in gas testsuite
08: bfin: correct macro use in gas testsuite
09: bfin: drop _ASSIGN_BANG
10: ia64: correct macro use in gas testsuite
11: MIPS: correct macro use in gas and ld testsuites
12: TilePro: correct macro use in gas testsuite
13: Arm: relax gas testsuite whitespace expectations
14: aarch64: relax gas testsuite whitespace expectations
15: MIPS: relax gas testsuite whitespace expectations
16: Sparc: relax gas testsuite whitespace expectations
17: have scrubber retain more whitespace

Jan

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 01/17] x86: accept whitespace inside curly braces
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
@ 2024-07-12 12:56 ` Jan Beulich
  2024-07-12 12:57 ` [PATCH v2 02/17] gas: drop scrubber state -2 Jan Beulich
                   ` (18 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 12:56 UTC (permalink / raw)
  To: Binutils; +Cc: H.J. Lu

Other than documented /**/ comments currently aren't really converted to
a single space, at least not for x86 in its most common configurations.
That'll be fixed subsequently, at which point blanks may appear where so
far none were expected. Furthermore not permitting blanks immediately
inside curly braces wasn't quite logical anyway - such constructs are
composite ones, and hence components ought to have been permitted to be
separated by whitespace from the very beginning.

With this we also don't care anymore whether the scrubber would remove
whitespace around curly braces, so move them from extra_symbol_chars[]
to operand_special_chars[].

Note: The new testcase doesn't actually exercise much (if any) of the
added code. It is being put in place to ensure that subsequently, when
that code actually comes into play, behavior remains the same.
---
v2: New.

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -526,7 +526,7 @@ static const unsigned char i386_seg_pref
 
 /* List of chars besides those in app.c:symbol_chars that can start an
    operand.  Used to prevent the scrubber eating vital white-space.  */
-const char extra_symbol_chars[] = "*%-([{}"
+const char extra_symbol_chars[] = "*%-(["
 #ifdef LEX_AT
 	"@"
 #endif
@@ -587,7 +587,7 @@ static char operand_chars[256];
 
 /* All non-digit non-letter characters that may occur in an operand and
    which aren't already in extra_symbol_chars[].  */
-static const char operand_special_chars[] = "$+,)._~/<>|&^!=:@]";
+static const char operand_special_chars[] = "$+,)._~/<>|&^!=:@]{}";
 
 /* md_assemble() always leaves the strings it's passed unaltered.  To
    effect this we maintain a stack of saved characters that we've smashed
@@ -7964,6 +7964,8 @@ parse_insn (const char *line, char *mnem
 	{
 	  ++mnem_p;
 	  ++l;
+	  if (is_space_char (*l))
+	    ++l;
 	}
       else if (mode == parse_pseudo_prefix)
 	break;
@@ -7981,6 +7983,8 @@ parse_insn (const char *line, char *mnem
 	  l++;
 	}
       /* Pseudo-prefixes end with a closing figure brace.  */
+      if (*mnemonic == '{' && is_space_char (*l))
+	++l;
       if (*mnemonic == '{' && *l == '}')
 	{
 	  *mnem_p++ = *l++;
@@ -14571,6 +14575,8 @@ check_VecOperations (char *op_string)
       if (*op_string == '{')
 	{
 	  op_string++;
+	  if (is_space_char (*op_string))
+	    op_string++;
 
 	  /* Check broadcasts.  */
 	  if (startswith (op_string, "1to"))
@@ -14741,6 +14747,8 @@ check_VecOperations (char *op_string)
 	  else
 	    goto unknown_vec_op;
 
+	  if (is_space_char (*op_string))
+	    op_string++;
 	  if (*op_string != '}')
 	    {
 	      as_bad (_("missing `}' in `%s'"), saved);
@@ -14748,8 +14756,6 @@ check_VecOperations (char *op_string)
 	    }
 	  op_string++;
 
-	  /* Strip whitespace since the addition of pseudo prefixes
-	     changed how the scrubber treats '{'.  */
 	  if (is_space_char (*op_string))
 	    ++op_string;
 
@@ -15411,10 +15417,17 @@ RC_SAE_immediate (const char *imm_start)
   if (*pstr != '{')
     return 0;
 
-  pstr = RC_SAE_specifier (pstr + 1);
+  pstr++;
+  if (is_space_char (*pstr))
+    pstr++;
+
+  pstr = RC_SAE_specifier (pstr);
   if (pstr == NULL)
     return 0;
 
+  if (is_space_char (*pstr))
+    pstr++;
+
   if (*pstr++ != '}')
     {
       as_bad (_("Missing '}': '%s'"), imm_start);
--- /dev/null
+++ b/gas/testsuite/gas/i386/curly.d
@@ -0,0 +1,28 @@
+#objdump: -dw
+#name: i386 curly braces with blanks
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <curly>:
+[ 	]*[a-f0-9]+:	62 f1 74 58 58 10    	vaddps \(%eax\)\{1to16\},%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 58 58 10    	vaddps \(%eax\)\{1to16\},%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 58 58 10    	vaddps \(%eax\)\{1to16\},%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 58 58 10    	vaddps \(%eax\)\{1to16\},%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 18 58 d0    	vaddps \{rn-sae\},%zmm0,%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 18 58 d0    	vaddps \{rn-sae\},%zmm0,%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 18 58 d0    	vaddps \{rn-sae\},%zmm0,%zmm1,%zmm2
+[ 	]*[a-f0-9]+:	62 f1 74 cb 58 d0    	vaddps %zmm0,%zmm1,%zmm2\{%k3\}\{z\}
+[ 	]*[a-f0-9]+:	62 f1 74 cb 58 d0    	vaddps %zmm0,%zmm1,%zmm2\{%k3\}\{z\}
+[ 	]*[a-f0-9]+:	62 f1 74 cb 58 d0    	vaddps %zmm0,%zmm1,%zmm2\{%k3\}\{z\}
+[ 	]*[a-f0-9]+:	62 f1 74 cb 58 d0    	vaddps %zmm0,%zmm1,%zmm2\{%k3\}\{z\}
+[ 	]*[a-f0-9]+:	62 f1 74 cb 58 d0    	vaddps %zmm0,%zmm1,%zmm2\{%k3\}\{z\}
+[ 	]*[a-f0-9]+:	62 f1 74 cb 58 d0    	vaddps %zmm0,%zmm1,%zmm2\{%k3\}\{z\}
+[ 	]*[a-f0-9]+:	62 f1 74 08 58 d0    	\{evex\} vaddps %xmm0,%xmm1,%xmm2
+[ 	]*[a-f0-9]+:	62 f1 74 08 58 d0    	\{evex\} vaddps %xmm0,%xmm1,%xmm2
+[ 	]*[a-f0-9]+:	62 f1 74 08 58 d0    	\{evex\} vaddps %xmm0,%xmm1,%xmm2
+[ 	]*[a-f0-9]+:	62 f1 74 18 58 c2    	vaddps \{rn-sae\},%zmm2,%zmm1,%zmm0
+[ 	]*[a-f0-9]+:	62 f1 74 18 58 c2    	vaddps \{rn-sae\},%zmm2,%zmm1,%zmm0
+[ 	]*[a-f0-9]+:	62 f1 74 18 58 c2    	vaddps \{rn-sae\},%zmm2,%zmm1,%zmm0
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/curly.s
@@ -0,0 +1,26 @@
+	.text
+curly:
+	vaddps	(%eax) {1to16}, %zmm1, %zmm2
+	vaddps	(%eax){ 1to16}, %zmm1, %zmm2
+	vaddps	(%eax){1to16 }, %zmm1, %zmm2
+	vaddps	(%eax){1to16} , %zmm1, %zmm2
+
+	vaddps	{ rn-sae}, %zmm0, %zmm1, %zmm2
+	vaddps	{rn-sae }, %zmm0, %zmm1, %zmm2
+	vaddps	{rn-sae} , %zmm0, %zmm1, %zmm2
+
+	vaddps	%zmm0, %zmm1, %zmm2 {%k3}{z}
+	vaddps	%zmm0, %zmm1, %zmm2{ %k3}{z}
+	vaddps	%zmm0, %zmm1, %zmm2{%k3 }{z}
+	vaddps	%zmm0, %zmm1, %zmm2{%k3} {z}
+	vaddps	%zmm0, %zmm1, %zmm2{%k3}{ z}
+	vaddps	%zmm0, %zmm1, %zmm2{%k3}{z }
+
+	{ evex} vaddps %xmm0, %xmm1, %xmm2
+	{evex } vaddps %xmm0, %xmm1, %xmm2
+	{evex}vaddps %xmm0, %xmm1, %xmm2
+
+	.intel_syntax noprefix
+	vaddps	zmm0, zmm1, zmm2 {rn-sae}
+	vaddps	zmm0, zmm1, zmm2{ rn-sae}
+	vaddps	zmm0, zmm1, zmm2{rn-sae }
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -105,6 +105,7 @@ if [gas_32_check] then {
     run_dump_test "equ"
     run_list_test "equ-2" "-al"
     run_list_test "equ-bad"
+    run_dump_test "curly"
     run_dump_test "divide"
     run_dump_test "quoted"
     run_dump_test "quoted2"


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 02/17] gas: drop scrubber state -2
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
  2024-07-12 12:56 ` [PATCH v2 01/17] x86: accept whitespace inside curly braces Jan Beulich
@ 2024-07-12 12:57 ` Jan Beulich
  2024-07-12 12:57 ` [PATCH v2 03/17] gas: pre-init the scrubber's lex[] Jan Beulich
                   ` (17 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 12:57 UTC (permalink / raw)
  To: Binutils; +Cc: H.J. Lu

On 12.07.2024 14:51, Jan Beulich wrote:
> The end goal is to finally deal with long standing issues in, in
> particular, macro handling (see e.g. b3446f947bd1 ["gas: retain
> whitespace between strings"]). That's the final patch. I've come
> across various other issues though, which some of the earlier
> patches aim at addressing. Imo those are (in principle, subject to
> feedback of course) fine to go in for 2.43. Whereas I'd prefer the
> final change to go in relatively early in a release cycle, to allow
> time to deal with real or perceived regressions (see patches 07-12
> for examples thereof).
> 
> One of the issues I'm facing in dealing with target specific
> adjustments is that there are 5 gas targets which don't even have a
> testsuite subdir:
> - m32c (no maintainer)
> - moxie
> - ns32k (no maintainer)
> - spu
> - tic30 (no maintainer)
> How is one supposed to have even the slightest idea whether a common
> code change breaks such a target (Cc-ing the two maintainers of the
> named targets which have one)? I'm already worried enough by targets
> having only a pretty "slim" set of test cases. In any event, target
> specific changes made in that final patch don't go much beyond what is
> needed to have the testsuite pass. I'm pretty sure further changes are
> going to be needed in perhaps many places; while I'll try to deal with
> those as they're being pointed out, I think target maintainers are in
> a better position to change what needs changing, as they ought to have
> a better idea than me where whitespace may occur and hence need
> skipping.
> 
> Doing better at skipping whitespace is, to some degree at least, also
> a prereq for -f (or its equivalent #NO_APP at the start of a file) to
> be reliable to use. It is probably for a reason that gcc currently
> doesn't use this for most targets.
> 
> Compared to v1 this is now passing the testsuite for a wide range of
> targets, thanks to various new patches and a number of target specific
> changes in the final one (the Arm64 testsuite adjustments in
> particular may already be insufficient again, though; I'll keep
> re-basing them). All patches individually detail what has changed, if
> anything.
> 
> There may be a contextual (but no functional) dependency on "x86: undo
> '{' being a symbol-start character" submitted earlier today.
> 
> 01: x86: accept whitespace inside curly braces
> 02: drop scrubber state -2
> 03: pre-init the scrubber's lex[]
> 04: re-work tic6x scrubber special case
> 05: consistently drop trailing whitespace when scrubbing
> 06: adjust impossible/bogus M68K/MRI special case when scrubbing
> 07: Arm: correct macro use in gas testsuite
> 08: bfin: correct macro use in gas testsuite
> 09: bfin: drop _ASSIGN_BANG
> 10: ia64: correct macro use in gas testsuite
> 11: MIPS: correct macro use in gas and ld testsuites
> 12: TilePro: correct macro use in gas testsuite
> 13: Arm: relax gas testsuite whitespace expectations
> 14: aarch64: relax gas testsuite whitespace expectations
> 15: MIPS: relax gas testsuite whitespace expectations
> 16: Sparc: relax gas testsuite whitespace expectations
> 17: have scrubber retain more whitespace
> 
> Jan


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 03/17] gas: pre-init the scrubber's lex[]
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
  2024-07-12 12:56 ` [PATCH v2 01/17] x86: accept whitespace inside curly braces Jan Beulich
  2024-07-12 12:57 ` [PATCH v2 02/17] gas: drop scrubber state -2 Jan Beulich
@ 2024-07-12 12:57 ` Jan Beulich
  2024-07-12 12:58 ` [PATCH v2 04/17] gas: drop tic6x scrubber special case Jan Beulich
                   ` (16 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 12:57 UTC (permalink / raw)
  To: Binutils; +Cc: Anthony Green, Alan Modra

While we can't - unlike an old comment suggests - do this fully, we can
certainly do part of this at compile time.

Since it's adjacent, also drop the unnecessary forward declaration of
process_escape().
---
I was actually considering to also move away from plain char[] as the
type of lex[], but then decided that I simply don't know why it was done
like this in the first place.
---
v2: Avoid using gcc extension.

--- a/gas/app.c
+++ b/gas/app.c
@@ -58,10 +58,6 @@ static const char * symver_state;
 
 static char last_char;
 
-static char lex[256];
-static const char symbol_chars[] =
-"$._ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
-
 #define LEX_IS_SYMBOL_COMPONENT		1
 #define LEX_IS_WHITESPACE		2
 #define LEX_IS_LINE_SEPARATOR		3
@@ -93,23 +89,73 @@ static const char symbol_chars[] =
 #define IS_LINE_COMMENT(c)		(lex[c] == LEX_IS_LINE_COMMENT_START)
 #define	IS_NEWLINE(c)			(lex[c] == LEX_IS_NEWLINE)
 
-static int process_escape (int);
-
-/* FIXME-soon: The entire lexer/parser thingy should be
-   built statically at compile time rather than dynamically
-   each and every time the assembler is run.  xoxorich.  */
+static char lex[256] = {
+  [' ']  = LEX_IS_WHITESPACE,
+  ['\t'] = LEX_IS_WHITESPACE,
+  ['\r'] = LEX_IS_WHITESPACE,
+  ['\n'] = LEX_IS_NEWLINE,
+  [':'] = LEX_IS_COLON,
+  ['$'] = LEX_IS_SYMBOL_COMPONENT,
+  ['.'] = LEX_IS_SYMBOL_COMPONENT,
+  ['_'] = LEX_IS_SYMBOL_COMPONENT,
+  ['A'] = LEX_IS_SYMBOL_COMPONENT, ['a'] = LEX_IS_SYMBOL_COMPONENT,
+  ['B'] = LEX_IS_SYMBOL_COMPONENT, ['b'] = LEX_IS_SYMBOL_COMPONENT,
+  ['C'] = LEX_IS_SYMBOL_COMPONENT, ['c'] = LEX_IS_SYMBOL_COMPONENT,
+  ['D'] = LEX_IS_SYMBOL_COMPONENT, ['d'] = LEX_IS_SYMBOL_COMPONENT,
+  ['E'] = LEX_IS_SYMBOL_COMPONENT, ['e'] = LEX_IS_SYMBOL_COMPONENT,
+  ['F'] = LEX_IS_SYMBOL_COMPONENT, ['f'] = LEX_IS_SYMBOL_COMPONENT,
+  ['G'] = LEX_IS_SYMBOL_COMPONENT, ['g'] = LEX_IS_SYMBOL_COMPONENT,
+  ['H'] = LEX_IS_SYMBOL_COMPONENT, ['h'] = LEX_IS_SYMBOL_COMPONENT,
+  ['I'] = LEX_IS_SYMBOL_COMPONENT, ['i'] = LEX_IS_SYMBOL_COMPONENT,
+  ['J'] = LEX_IS_SYMBOL_COMPONENT, ['j'] = LEX_IS_SYMBOL_COMPONENT,
+  ['K'] = LEX_IS_SYMBOL_COMPONENT, ['k'] = LEX_IS_SYMBOL_COMPONENT,
+  ['L'] = LEX_IS_SYMBOL_COMPONENT, ['l'] = LEX_IS_SYMBOL_COMPONENT,
+  ['M'] = LEX_IS_SYMBOL_COMPONENT, ['m'] = LEX_IS_SYMBOL_COMPONENT,
+  ['N'] = LEX_IS_SYMBOL_COMPONENT, ['n'] = LEX_IS_SYMBOL_COMPONENT,
+  ['O'] = LEX_IS_SYMBOL_COMPONENT, ['o'] = LEX_IS_SYMBOL_COMPONENT,
+  ['P'] = LEX_IS_SYMBOL_COMPONENT, ['p'] = LEX_IS_SYMBOL_COMPONENT,
+  ['Q'] = LEX_IS_SYMBOL_COMPONENT, ['q'] = LEX_IS_SYMBOL_COMPONENT,
+  ['R'] = LEX_IS_SYMBOL_COMPONENT, ['r'] = LEX_IS_SYMBOL_COMPONENT,
+  ['S'] = LEX_IS_SYMBOL_COMPONENT, ['s'] = LEX_IS_SYMBOL_COMPONENT,
+  ['T'] = LEX_IS_SYMBOL_COMPONENT, ['t'] = LEX_IS_SYMBOL_COMPONENT,
+  ['U'] = LEX_IS_SYMBOL_COMPONENT, ['u'] = LEX_IS_SYMBOL_COMPONENT,
+  ['V'] = LEX_IS_SYMBOL_COMPONENT, ['v'] = LEX_IS_SYMBOL_COMPONENT,
+  ['W'] = LEX_IS_SYMBOL_COMPONENT, ['w'] = LEX_IS_SYMBOL_COMPONENT,
+  ['X'] = LEX_IS_SYMBOL_COMPONENT, ['x'] = LEX_IS_SYMBOL_COMPONENT,
+  ['Y'] = LEX_IS_SYMBOL_COMPONENT, ['y'] = LEX_IS_SYMBOL_COMPONENT,
+  ['Z'] = LEX_IS_SYMBOL_COMPONENT, ['z'] = LEX_IS_SYMBOL_COMPONENT,
+  ['0'] = LEX_IS_SYMBOL_COMPONENT,
+  ['1'] = LEX_IS_SYMBOL_COMPONENT,
+  ['2'] = LEX_IS_SYMBOL_COMPONENT,
+  ['3'] = LEX_IS_SYMBOL_COMPONENT,
+  ['4'] = LEX_IS_SYMBOL_COMPONENT,
+  ['5'] = LEX_IS_SYMBOL_COMPONENT,
+  ['6'] = LEX_IS_SYMBOL_COMPONENT,
+  ['7'] = LEX_IS_SYMBOL_COMPONENT,
+  ['8'] = LEX_IS_SYMBOL_COMPONENT,
+  ['9'] = LEX_IS_SYMBOL_COMPONENT,
+#define INIT2(n) [n] = LEX_IS_SYMBOL_COMPONENT, \
+		 [(n) + 1] = LEX_IS_SYMBOL_COMPONENT
+#define INIT4(n)    INIT2 (n),  INIT2 ((n) +  2)
+#define INIT8(n)    INIT4 (n),  INIT4 ((n) +  4)
+#define INIT16(n)   INIT8 (n),  INIT8 ((n) +  8)
+#define INIT32(n)  INIT16 (n), INIT16 ((n) + 16)
+#define INIT64(n)  INIT32 (n), INIT32 ((n) + 32)
+#define INIT128(n) INIT64 (n), INIT64 ((n) + 64)
+  INIT128 (128),
+#undef INIT128
+#undef INIT64
+#undef INIT32
+#undef INIT16
+#undef INIT8
+#undef INIT4
+#undef INIT2
+};
 
 void
 do_scrub_begin (int m68k_mri ATTRIBUTE_UNUSED)
 {
   const char *p;
-  int c;
-
-  lex[' '] = LEX_IS_WHITESPACE;
-  lex['\t'] = LEX_IS_WHITESPACE;
-  lex['\r'] = LEX_IS_WHITESPACE;
-  lex['\n'] = LEX_IS_NEWLINE;
-  lex[':'] = LEX_IS_COLON;
 
 #ifdef TC_M68K
   scrub_m68k_mri = m68k_mri;
@@ -133,11 +179,6 @@ do_scrub_begin (int m68k_mri ATTRIBUTE_U
 
   /* Note that these override the previous defaults, e.g. if ';' is a
      comment char, then it isn't a line separator.  */
-  for (p = symbol_chars; *p; ++p)
-    lex[(unsigned char) *p] = LEX_IS_SYMBOL_COMPONENT;
-
-  for (c = 128; c < 256; ++c)
-    lex[c] = LEX_IS_SYMBOL_COMPONENT;
 
 #ifdef tc_symbol_chars
   /* This macro permits the processor to specify all characters which


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 04/17] gas: drop tic6x scrubber special case
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (2 preceding siblings ...)
  2024-07-12 12:57 ` [PATCH v2 03/17] gas: pre-init the scrubber's lex[] Jan Beulich
@ 2024-07-12 12:58 ` Jan Beulich
  2024-07-12 13:00 ` [PATCH v2 05/17] gas: consistently drop trailing whitespace when scrubbing Jan Beulich
                   ` (15 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 12:58 UTC (permalink / raw)
  To: Binutils; +Cc: Joseph S. Myers

Two successive PUT() without a state change in between can't be right:
The first PUT() may take the "goto tofull" path, leading to the
subsequent character being processed later in the previously set state
(1 in this case), rather than the state we were in upon entry to the
switch() (13 in this case).

However, the original purpose of that logic appears to be to not mistake
"|| ^" for "||^". This effect, sadly, looks to not have been achieved.
Therefore drop the special case altogether; something that actually
achieves the (presumably) intended effect may then be introduced down
the road.
---
v2: Drop entirely.

--- a/gas/app.c
+++ b/gas/app.c
@@ -737,16 +737,6 @@ do_scrub_chars (size_t (*get) (char *, s
 	     line from just after the first white space.  */
 	  state = 1;
 	  PUT ('|');
-#ifdef TC_TIC6X
-	  /* "||^" is used for SPMASKed instructions.  */
-	  ch = GET ();
-	  if (ch == EOF)
-	    goto fromeof;
-	  else if (ch == '^')
-	    PUT ('^');
-	  else
-	    UNGET (ch);
-#endif
 	  continue;
 #endif
 #ifdef TC_Z80


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 05/17] gas: consistently drop trailing whitespace when scrubbing
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (3 preceding siblings ...)
  2024-07-12 12:58 ` [PATCH v2 04/17] gas: drop tic6x scrubber special case Jan Beulich
@ 2024-07-12 13:00 ` Jan Beulich
  2024-07-15 12:10   ` Maciej W. Rozycki
  2024-07-12 13:01 ` [PATCH v2 06/17] gas: adjust impossible/bogus M68K/MRI special case " Jan Beulich
                   ` (14 subsequent siblings)
  19 siblings, 1 reply; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:00 UTC (permalink / raw)
  To: Binutils; +Cc: Maciej W. Rozycki, Chenghua Xu

From especially the checks for the two separator forms it appears to
follow that the construct being touched is about trailing whitespace. In
such a case, considering that for many targets ordinary and line comment
chars overlap, take into account that line comment chars override
ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually
depends on that ordering, and also accounts for this overriding).

Plus of course IS_NEWLINE() would better also be consulted. Note also
that the DOUBLESLASH_LINE_COMMENTS change should generally have no
effect just yet; it's a prereq for a later change but better fits here.

Leave respective comments as well, and update documentation to correct
which comment form is actually replaced by a single blank (i.e. neither
the ones starting with what {,tc_}comment_chars[] has nor the ones
starting with what line_comment_chars[] has).
---
Why are there both comment_chars[] and tc_comment_chars[]? The former is
per-arch anyway, so why would there be a need for an arch override? Is
this perhaps merely a historical leftover, which could be eliminated?
---
v2: Drop the trailing blanks in the MIPS testcases being touched.

--- a/gas/app.c
+++ b/gas/app.c
@@ -87,6 +87,7 @@ static char last_char;
 #define IS_PARALLEL_SEPARATOR(c)	(lex[c] == LEX_IS_PARALLEL_SEPARATOR)
 #define IS_COMMENT(c)			(lex[c] == LEX_IS_COMMENT_START)
 #define IS_LINE_COMMENT(c)		(lex[c] == LEX_IS_LINE_COMMENT_START)
+#define IS_TWOCHAR_COMMENT_1ST(c)	(lex[c] == LEX_IS_TWOCHAR_COMMENT_1ST)
 #define	IS_NEWLINE(c)			(lex[c] == LEX_IS_NEWLINE)
 
 static char lex[256] = {
@@ -197,6 +198,9 @@ do_scrub_begin (int m68k_mri ATTRIBUTE_U
   for (p = tc_comment_chars; *p; p++)
     lex[(unsigned char) *p] = LEX_IS_COMMENT_START;
 
+  /* While counter intuitive to have more special purpose line comment chars
+     override more general purpose ordinary ones, logic in do_scrub_chars()
+     depends on this ordering.   */
   for (p = line_comment_chars; *p; p++)
     lex[(unsigned char) *p] = LEX_IS_LINE_COMMENT_START;
 
@@ -930,7 +934,12 @@ do_scrub_chars (size_t (*get) (char *, s
 		}
 	    }
 #endif
+
+	  /* Prune trailing whitespace.  */
 	  if (IS_COMMENT (ch)
+	      || (IS_LINE_COMMENT (ch)
+	          && (state < 1 || strchr (tc_comment_chars, ch)))
+	      || IS_NEWLINE (ch)
 	      || IS_LINE_SEPARATOR (ch)
 	      || IS_PARALLEL_SEPARATOR (ch))
 	    {
@@ -943,6 +952,16 @@ do_scrub_chars (size_t (*get) (char *, s
 		}
 	      goto recycle;
 	    }
+#ifdef DOUBLESLASH_LINE_COMMENTS
+	  if (IS_TWOCHAR_COMMENT_1ST (ch))
+	    {
+	      ch2 = GET ();
+	      if (ch2 != EOF)
+	        UNGET (ch2);
+	      if (ch2 == '/')
+		goto recycle;
+	    }
+#endif
 
 	  /* If we're in state 2 or 11, we've seen a non-white
 	     character followed by whitespace.  If the next character
--- a/gas/doc/as.texi
+++ b/gas/doc/as.texi
@@ -2987,11 +2987,11 @@ as exactly one space.
 @section Comments
 
 @cindex comments
-There are two ways of rendering comments to @command{@value{AS}}.  In both
-cases the comment is equivalent to one space.
+There are two ways of rendering comments to @command{@value{AS}}.
 
 Anything from @samp{/*} through the next @samp{*/} is a comment.
-This means you may not nest these comments.
+This means you may not nest these comments.  Such a comment is equivalent to
+one space, plus bumping the line counter accordingly.
 
 @smallexample
 /*
--- a/gas/testsuite/gas/mips/mips16-32@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16-32@mips16-insn-e.l
@@ -25,7 +25,7 @@
 .*:50: Warning: extended operand requested but not required
 .*:51: Error: opcode not supported on this processor: mips1 \(mips1\) `restore\.e 128'
 .*:52: Error: opcode not supported on this processor: mips1 \(mips1\) `save\.e 128'
-.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e '
+.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e'
 .*:54: Error: unrecognized extended version of MIPS16 opcode `move\.e \$0,\$16'
 .*:55: Error: unrecognized extended version of MIPS16 opcode `move\.e \$16,\$0'
 .*:57: Warning: extended operand requested but not required
@@ -71,7 +71,7 @@
 .*:123: Error: unrecognized extended version of MIPS16 opcode `srav\.e \$16,\$16'
 .*:124: Error: operand 2 must be an immediate expression `sra\.e \$16,\$16'
 .*:125: Error: opcode not supported on this processor: mips1 \(mips1\) `dsrl\.e \$16,8'
-.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e '
+.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e'
 .*:127: Error: unrecognized extended version of MIPS16 opcode `entry\.e \$31'
 .*:128: Error: unrecognized extended version of MIPS16 opcode `exit\.e \$f0'
 .*:129: Error: unrecognized extended version of MIPS16 opcode `exit\.e'
--- a/gas/testsuite/gas/mips/mips16-64@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16-64@mips16-insn-e.l
@@ -25,7 +25,7 @@
 .*:50: Warning: extended operand requested but not required
 .*:51: Error: opcode not supported on this processor: mips3 \(mips3\) `restore\.e 128'
 .*:52: Error: opcode not supported on this processor: mips3 \(mips3\) `save\.e 128'
-.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e '
+.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e'
 .*:54: Error: unrecognized extended version of MIPS16 opcode `move\.e \$0,\$16'
 .*:55: Error: unrecognized extended version of MIPS16 opcode `move\.e \$16,\$0'
 .*:57: Warning: extended operand requested but not required
@@ -71,7 +71,7 @@
 .*:123: Error: unrecognized extended version of MIPS16 opcode `srav\.e \$16,\$16'
 .*:124: Error: operand 2 must be an immediate expression `sra\.e \$16,\$16'
 .*:125: Warning: extended operand requested but not required
-.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e '
+.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e'
 .*:127: Error: unrecognized extended version of MIPS16 opcode `entry\.e \$31'
 .*:128: Error: unrecognized extended version of MIPS16 opcode `exit\.e \$f0'
 .*:129: Error: unrecognized extended version of MIPS16 opcode `exit\.e'
--- a/gas/testsuite/gas/mips/mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16-insn-e.l
@@ -23,7 +23,7 @@
 .*:48: Warning: extended operand requested but not required
 .*:49: Warning: extended operand requested but not required
 .*:50: Warning: extended operand requested but not required
-.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e '
+.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e'
 .*:54: Error: unrecognized extended version of MIPS16 opcode `move\.e \$0,\$16'
 .*:55: Error: unrecognized extended version of MIPS16 opcode `move\.e \$16,\$0'
 .*:57: Warning: extended operand requested but not required
@@ -69,7 +69,7 @@
 .*:123: Error: unrecognized extended version of MIPS16 opcode `srav\.e \$16,\$16'
 .*:124: Error: operand 2 must be an immediate expression `sra\.e \$16,\$16'
 .*:125: Warning: extended operand requested but not required
-.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e '
+.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e'
 .*:127: Error: unrecognized extended version of MIPS16 opcode `entry\.e \$31'
 .*:128: Error: unrecognized extended version of MIPS16 opcode `exit\.e \$f0'
 .*:129: Error: unrecognized extended version of MIPS16 opcode `exit\.e'
--- a/gas/testsuite/gas/mips/mips16e-32@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16e-32@mips16-insn-e.l
@@ -23,7 +23,7 @@
 .*:48: Warning: extended operand requested but not required
 .*:49: Warning: extended operand requested but not required
 .*:50: Warning: extended operand requested but not required
-.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e '
+.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e'
 .*:54: Error: unrecognized extended version of MIPS16 opcode `move\.e \$0,\$16'
 .*:55: Error: unrecognized extended version of MIPS16 opcode `move\.e \$16,\$0'
 .*:57: Warning: extended operand requested but not required
@@ -69,7 +69,7 @@
 .*:123: Error: unrecognized extended version of MIPS16 opcode `srav\.e \$16,\$16'
 .*:124: Error: operand 2 must be an immediate expression `sra\.e \$16,\$16'
 .*:125: Error: opcode not supported on this processor: mips32 \(mips32\) `dsrl\.e \$16,8'
-.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e '
+.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e'
 .*:127: Error: unrecognized extended version of MIPS16 opcode `entry\.e \$31'
 .*:128: Error: unrecognized extended version of MIPS16 opcode `exit\.e \$f0'
 .*:129: Error: unrecognized extended version of MIPS16 opcode `exit\.e'
--- a/gas/testsuite/gas/mips/mips16e2-32@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16e2-32@mips16-insn-e.l
@@ -23,7 +23,7 @@
 .*:48: Warning: extended operand requested but not required
 .*:49: Warning: extended operand requested but not required
 .*:50: Warning: extended operand requested but not required
-.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e '
+.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e'
 .*:54: Error: unrecognized extended version of MIPS16 opcode `move\.e \$0,\$16'
 .*:55: Error: unrecognized extended version of MIPS16 opcode `move\.e \$16,\$0'
 .*:57: Warning: extended operand requested but not required
@@ -69,7 +69,7 @@
 .*:123: Error: unrecognized extended version of MIPS16 opcode `srav\.e \$16,\$16'
 .*:124: Error: operand 2 must be an immediate expression `sra\.e \$16,\$16'
 .*:125: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `dsrl\.e \$16,8'
-.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e '
+.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e'
 .*:127: Error: unrecognized extended version of MIPS16 opcode `entry\.e \$31'
 .*:128: Error: unrecognized extended version of MIPS16 opcode `exit\.e \$f0'
 .*:129: Error: unrecognized extended version of MIPS16 opcode `exit\.e'
--- a/gas/testsuite/gas/mips/mips16e2-interaptiv-mr2@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16e2-interaptiv-mr2@mips16-insn-e.l
@@ -23,7 +23,7 @@
 .*:48: Warning: extended operand requested but not required
 .*:49: Warning: extended operand requested but not required
 .*:50: Warning: extended operand requested but not required
-.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e '
+.*:53: Error: unrecognized extended version of MIPS16 opcode `nop\.e'
 .*:54: Error: unrecognized extended version of MIPS16 opcode `move\.e \$0,\$16'
 .*:55: Error: unrecognized extended version of MIPS16 opcode `move\.e \$16,\$0'
 .*:57: Warning: extended operand requested but not required
@@ -69,7 +69,7 @@
 .*:123: Error: unrecognized extended version of MIPS16 opcode `srav\.e \$16,\$16'
 .*:124: Error: operand 2 must be an immediate expression `sra\.e \$16,\$16'
 .*:125: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `dsrl\.e \$16,8'
-.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e '
+.*:126: Error: unrecognized extended version of MIPS16 opcode `entry\.e'
 .*:127: Error: unrecognized extended version of MIPS16 opcode `entry\.e \$31'
 .*:128: Error: unrecognized extended version of MIPS16 opcode `exit\.e \$f0'
 .*:129: Error: unrecognized extended version of MIPS16 opcode `exit\.e'


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 06/17] gas: adjust impossible/bogus M68K/MRI special case when scrubbing
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (4 preceding siblings ...)
  2024-07-12 13:00 ` [PATCH v2 05/17] gas: consistently drop trailing whitespace when scrubbing Jan Beulich
@ 2024-07-12 13:01 ` Jan Beulich
  2024-07-12 13:02 ` [PATCH v2 07/17] Arm: correct macro use in gas testsuite Jan Beulich
                   ` (13 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:01 UTC (permalink / raw)
  To: Binutils; +Cc: Stephane Carrez, Sean Keys

State 1 is uniformly handled further up. And it is highly questionable
that in state 10 (i.e. after having seen not only a possible label, but
also an opcode), which is about to go away anyway, a line comment char
could still be meant to take effect. With the state checking dropped,
the immediately preceding logic can then also be simplified.
---
v2: New.

--- a/gas/app.c
+++ b/gas/app.c
@@ -1331,14 +1331,10 @@ do_scrub_chars (size_t (*get) (char *, s
 	     start of a line.  If this is also a normal comment
 	     character, fall through.  Otherwise treat it as a default
 	     character.  */
-	  if (strchr (tc_comment_chars, ch) == NULL
-	      && (! scrub_m68k_mri
-		  || (ch != '!' && ch != '*')))
+	  if (strchr (tc_comment_chars, ch) == NULL)
 	    goto de_fault;
 	  if (scrub_m68k_mri
-	      && (ch == '!' || ch == '*' || ch == '#')
-	      && state != 1
-	      && state != 10)
+	      && (ch == '!' || ch == '*' || ch == '#'))
 	    goto de_fault;
 	  /* Fall through.  */
 	case LEX_IS_COMMENT_START:


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 07/17] Arm: correct macro use in gas testsuite
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (5 preceding siblings ...)
  2024-07-12 13:01 ` [PATCH v2 06/17] gas: adjust impossible/bogus M68K/MRI special case " Jan Beulich
@ 2024-07-12 13:02 ` Jan Beulich
  2024-07-12 13:03 ` [PATCH v2 08/17] bfin: " Jan Beulich
                   ` (12 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:02 UTC (permalink / raw)
  To: Binutils; +Cc: Nick Clifton, ramana.radhakrishnan, Richard Earnshaw

The way the inner macro invocations are written doesn't quite work as
expected (and would actually break subsequently): Due to overly
aggressive removal of whitespace by the scrubber, the incoming \sym and
\offset arguments actually get concatenated; an empty 3rd argument is
being passed to ldrtest2. That just so happened to work as intended; any
use of \offset alone would have exposed the problem. Quote the 3rd
argument, thus retaining enough whitespace to be independent of scrubber
internals.

--- a/gas/testsuite/gas/arm/group-reloc-ldrs-encoding-bad.s
+++ b/gas/testsuite/gas/arm/group-reloc-ldrs-encoding-bad.s
@@ -14,7 +14,7 @@
 
 	.macro ldrtest load store sym offset
 
-	ldrtest2 \load \sym \offset
+	ldrtest2 \load \sym "\offset"
 
 	\store	r0, [r0, #:pc_g1:(\sym \offset)]
 	\store	r0, [r0, #:pc_g2:(\sym \offset)]
--- a/gas/testsuite/gas/arm/group-reloc-ldrs.s
+++ b/gas/testsuite/gas/arm/group-reloc-ldrs.s
@@ -14,7 +14,7 @@
 
 	.macro ldrtest load store sym offset
 
-	ldrtest2 \load \sym \offset
+	ldrtest2 \load \sym "\offset"
 
 	\store	r0, [r0, #:pc_g1:(\sym \offset)]
 	\store	r0, [r0, #:pc_g2:(\sym \offset)]


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 08/17] bfin: correct macro use in gas testsuite
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (6 preceding siblings ...)
  2024-07-12 13:02 ` [PATCH v2 07/17] Arm: correct macro use in gas testsuite Jan Beulich
@ 2024-07-12 13:03 ` Jan Beulich
  2024-07-12 13:04 ` [PATCH v2 09/17] bfin: drop _ASSIGN_BANG Jan Beulich
                   ` (11 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:03 UTC (permalink / raw)
  To: Binutils; +Cc: Jie Zhang, Mike Frysinger

Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter really isn't an option here.
---
v2: New.

--- a/gas/testsuite/gas/bfin/allinsn16.s
+++ b/gas/testsuite/gas/bfin/allinsn16.s
@@ -12,16 +12,16 @@
 # iterate 0x20 times
 .macro _dw b, i, e
 	.if \i < \e
-		__dw \b, \i, \i + 0x40
-		_dw \b, \i + 0x40, \e
+		__dw \b, \i, (\i + 0x40)
+		_dw \b, (\i + 0x40), \e
 	.endif
 .endm
 
 # iterate 0x4 times
 .macro dw b, i, e
 	.if \i < \e
-		_dw \b, \i, \i + 0x800
-		dw \b, \i + 0x800, \e
+		_dw \b, \i, (\i + 0x800)
+		dw \b, (\i + 0x800), \e
 	.endif
 .endm
 


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 09/17] bfin: drop _ASSIGN_BANG
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (7 preceding siblings ...)
  2024-07-12 13:03 ` [PATCH v2 08/17] bfin: " Jan Beulich
@ 2024-07-12 13:04 ` Jan Beulich
  2024-07-12 13:05 ` [PATCH v2 10/17] ia64: correct macro use in gas testsuite Jan Beulich
                   ` (10 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:04 UTC (permalink / raw)
  To: Binutils; +Cc: Jie Zhang, Mike Frysinger

A few testcases demonstrate that "=!" isn't supposed to be an
individual token, since "= !" is used in a number of places. So far
lexing that to a single token worked because of the scrubber being
overly aggressive in removing whitespace. As that's going to change,
replace uses by separate ASSIGN and BANG.
---
v2: New.

--- a/gas/config/bfin-lex.l
+++ b/gas/config/bfin-lex.l
@@ -287,7 +287,6 @@ int yylex (void);
 "%"                     return PERCENT;
 "!"                     return BANG;
 ";"                     return SEMICOLON;
-"=!"			return _ASSIGN_BANG;
 "||"			return DOUBLE_BAR;
 "@"			return AT;
 <KEYWORD>[pP][rR][eE][fF][eE][tT][cC][hH]        return PREFETCH;
--- a/gas/config/bfin-parse.y
+++ b/gas/config/bfin-parse.y
@@ -529,7 +529,7 @@ dsp32shiftimm in slot1 and P-reg Store i
 %token _MINUS_ASSIGN _PLUS_ASSIGN
 
 /* Assignments, comparisons.  */
-%token _ASSIGN_BANG _LESS_THAN_ASSIGN _ASSIGN_ASSIGN
+%token _LESS_THAN_ASSIGN _ASSIGN_ASSIGN
 %token GE LT LE GT
 %token LESS_THAN
 
@@ -1804,7 +1804,7 @@ asm_1:
 	    return yyerror ("Only 'Dreg = CC' supported");
 	}
 
-	| CCREG _ASSIGN_BANG CCREG
+	| CCREG ASSIGN BANG CCREG
 	{
 	  notethat ("CC2dreg: CC =! CC\n");
 	  $$ = bfin_gen_cc2dreg (3, 0);
@@ -2471,12 +2471,12 @@ asm_1:
 	    return yyerror ("Register mismatch");
 	}
 
-	| CCREG _ASSIGN_BANG BITTST LPAREN REG COMMA expr RPAREN
+	| CCREG ASSIGN BANG BITTST LPAREN REG COMMA expr RPAREN
 	{
-	  if (IS_DREG ($5) && IS_UIMM ($7, 5))
+	  if (IS_DREG ($6) && IS_UIMM ($8, 5))
 	    {
 	      notethat ("LOGI2op: CC =! BITTST (dregs , uimm5 )\n");
-	      $$ = LOGI2OP ($5, uimm5 ($7), 0);
+	      $$ = LOGI2OP ($6, uimm5 ($8), 0);
 	    }
 	  else
 	    return yyerror ("Register mismatch or value error");


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 10/17] ia64: correct macro use in gas testsuite
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (8 preceding siblings ...)
  2024-07-12 13:04 ` [PATCH v2 09/17] bfin: drop _ASSIGN_BANG Jan Beulich
@ 2024-07-12 13:05 ` Jan Beulich
  2024-07-12 13:06 ` [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites Jan Beulich
                   ` (9 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:05 UTC (permalink / raw)
  To: Binutils; +Cc: Jim Wilson

Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate here.
---
v2: New.

--- a/gas/testsuite/gas/ia64/pcrel.s
+++ b/gas/testsuite/gas/ia64/pcrel.s
@@ -13,27 +13,27 @@ _&n:
 _e&n:
 .endm
 
-.macro m1 op, opnd1
+.macro m1 op, opnd1:vararg
  .align 16
 	op		opnd1 _e&op - _&op
 .endm
-.macro m2 op, opnd1
+.macro m2 op, opnd1:vararg
  .align 16
 	op		opnd1 @pcrel(esym)
 .endm
-.macro m3 op, opnd1
+.macro m3 op, opnd1:vararg
  .align 16
 	op		opnd1 esym - _&op
 .endm
-.macro m4 op, opnd1
+.macro m4 op, opnd1:vararg
  .align 16
 	op		opnd1 esym - .
 .endm
-.macro m5 op, opnd1
+.macro m5 op, opnd1:vararg
  .align 16
 	op		opnd1 esym - _e&op
 .endm
-.macro m6 op, opnd1
+.macro m6 op, opnd1:vararg
  .align 16
 	op		opnd1 0
 .endm


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (9 preceding siblings ...)
  2024-07-12 13:05 ` [PATCH v2 10/17] ia64: correct macro use in gas testsuite Jan Beulich
@ 2024-07-12 13:06 ` Jan Beulich
  2024-07-15 12:11   ` Maciej W. Rozycki
  2024-07-12 13:07 ` [PATCH v2 12/17] TilePro: correct macro use in gas testsuite Jan Beulich
                   ` (8 subsequent siblings)
  19 siblings, 1 reply; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:06 UTC (permalink / raw)
  To: Binutils; +Cc: Maciej W. Rozycki, Chenghua Xu

Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
former appears more appropriate here, as the macro parameters already
have ":req".
---
v2: New.

--- a/gas/testsuite/gas/mips/unaligned-branch-1.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-1.s
@@ -116,7 +116,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -127,7 +127,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-2.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-2.s
@@ -117,7 +117,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -129,7 +129,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-micromips-1.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-micromips-1.s
@@ -181,7 +181,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -192,7 +192,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-micromips-2.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-micromips-2.s
@@ -182,7 +182,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -194,7 +194,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-mips16-1.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-mips16-1.s
@@ -85,7 +85,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -96,7 +96,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-mips16-2.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-mips16-2.s
@@ -86,7 +86,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -98,7 +98,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-r6-1.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-r6-1.s
@@ -118,7 +118,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -129,7 +129,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-r6-2.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-r6-2.s
@@ -118,7 +118,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -129,7 +129,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-r6-3.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-r6-3.s
@@ -119,7 +119,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -131,7 +131,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-branch-r6-4.s
+++ b/gas/testsuite/gas/mips/unaligned-branch-r6-4.s
@@ -119,7 +119,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -131,7 +131,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-jump-1.s
+++ b/gas/testsuite/gas/mips/unaligned-jump-1.s
@@ -116,7 +116,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -127,7 +127,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-jump-2.s
+++ b/gas/testsuite/gas/mips/unaligned-jump-2.s
@@ -117,7 +117,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -129,7 +129,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-jump-micromips-1.s
+++ b/gas/testsuite/gas/mips/unaligned-jump-micromips-1.s
@@ -149,7 +149,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -160,7 +160,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-jump-micromips-2.s
+++ b/gas/testsuite/gas/mips/unaligned-jump-micromips-2.s
@@ -150,7 +150,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -162,7 +162,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-jump-mips16-1.s
+++ b/gas/testsuite/gas/mips/unaligned-jump-mips16-1.s
@@ -85,7 +85,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -96,7 +96,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/gas/testsuite/gas/mips/unaligned-jump-mips16-2.s
+++ b/gas/testsuite/gas/mips/unaligned-jump-mips16-2.s
@@ -86,7 +86,7 @@ bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	obj	\n - 1
+	obj	"\n - 1"
 	.endif
 	.endm
 
@@ -98,7 +98,7 @@ bar\@ :
 	.hword	0
 	.size	bar\@, . - bar\@
 	.if	\n - 1
-	fun	\n - 1
+	fun	"\n - 1"
 	.endif
 	.endm
 
--- a/ld/testsuite/ld-mips-elf/unaligned-data.s
+++ b/ld/testsuite/ld-mips-elf/unaligned-data.s
@@ -5,7 +5,7 @@
 bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
-	sym	\n - 1
+	sym	"\n - 1"
 	.endif
 	.endm
 
--- a/ld/testsuite/ld-mips-elf/unaligned-insn.s
+++ b/ld/testsuite/ld-mips-elf/unaligned-insn.s
@@ -6,7 +6,7 @@ bar\@ :
 	.insn
 	.hword	0
 	.size	bar\@, . - bar\@
-	sym	\n - 1
+	sym	"\n - 1"
 	.endif
 	.endm
 
--- a/ld/testsuite/ld-mips-elf/unaligned-text.s
+++ b/ld/testsuite/ld-mips-elf/unaligned-text.s
@@ -5,7 +5,7 @@
 bar\@ :
 	.byte	0
 	.size	bar\@, . - bar\@
-	sym	\n - 1
+	sym	"\n - 1"
 	.endif
 	.endm
 


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 12/17] TilePro: correct macro use in gas testsuite
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (10 preceding siblings ...)
  2024-07-12 13:06 ` [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites Jan Beulich
@ 2024-07-12 13:07 ` Jan Beulich
  2024-07-12 13:07 ` [PATCH v2 13/17] Arm: relax gas testsuite whitespace expectations Jan Beulich
                   ` (7 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:07 UTC (permalink / raw)
  To: Binutils; +Cc: Walter Lee

Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate (and far less intrusive) here.
---
v2: New.

--- a/gas/testsuite/gas/tilepro/t_constants.s
+++ b/gas/testsuite/gas/tilepro/t_constants.s
@@ -245,7 +245,7 @@ label_2:
 	.word -1311808516 - (272825489 - 19388681)
 	.int 19338670 + 260459768
 
-.macro .safe_word val
+.macro .safe_word val:vararg
 	.word (\val) & 0xffffffff
 .endm
 	


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 13/17] Arm: relax gas testsuite whitespace expectations
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (11 preceding siblings ...)
  2024-07-12 13:07 ` [PATCH v2 12/17] TilePro: correct macro use in gas testsuite Jan Beulich
@ 2024-07-12 13:07 ` Jan Beulich
  2024-07-12 13:10 ` [PATCH v2 14/17] aarch64: " Jan Beulich
                   ` (6 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:07 UTC (permalink / raw)
  To: Binutils; +Cc: Nick Clifton, ramana.radhakrishnan, Richard Earnshaw

In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
---
This is adding just the blanks that are going to be needed; imo it would
generally be better if test case expectations were, from the very
beginning, written to focus on what is being tested, rather than taking
verbatim copies of the respective tool's output.

--- a/gas/testsuite/gas/arm/addthumb2err.l
+++ b/gas/testsuite/gas/arm/addthumb2err.l
@@ -1,21 +1,21 @@
 [^:]*: Assembler messages:
-[^:]*:9: Error: shift value over 3 not allowed in thumb mode -- `add sp,sp,r0,LSL#4'
-[^:]*:10: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,LSR#3'
-[^:]*:11: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,ASR#3'
-[^:]*:12: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,ROR#3'
+[^:]*:9: Error: shift value over 3 not allowed in thumb mode -- `add sp,sp,r0,LSL ?#4'
+[^:]*:10: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,LSR ?#3'
+[^:]*:11: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,ASR ?#3'
+[^:]*:12: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,ROR ?#3'
 [^:]*:13: Error: only LSL shift allowed in thumb mode -- `add sp,sp,r0,RRX'
-[^:]*:14: Error: shift value over 3 not allowed in thumb mode -- `adds sp,sp,r0,LSL#4'
-[^:]*:15: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,LSR#3'
-[^:]*:16: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,ASR#3'
-[^:]*:17: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,ROR#3'
+[^:]*:14: Error: shift value over 3 not allowed in thumb mode -- `adds sp,sp,r0,LSL ?#4'
+[^:]*:15: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,LSR ?#3'
+[^:]*:16: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,ASR ?#3'
+[^:]*:17: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,ROR ?#3'
 [^:]*:18: Error: only LSL shift allowed in thumb mode -- `adds sp,sp,r0,RRX'
-[^:]*:19: Error: shift value over 3 not allowed in thumb mode -- `sub sp,sp,r0,LSL#4'
-[^:]*:20: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,LSR#3'
-[^:]*:21: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,ASR#3'
-[^:]*:22: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,ROR#3'
+[^:]*:19: Error: shift value over 3 not allowed in thumb mode -- `sub sp,sp,r0,LSL ?#4'
+[^:]*:20: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,LSR ?#3'
+[^:]*:21: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,ASR ?#3'
+[^:]*:22: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,ROR ?#3'
 [^:]*:23: Error: only LSL shift allowed in thumb mode -- `sub sp,sp,r0,RRX'
-[^:]*:24: Error: shift value over 3 not allowed in thumb mode -- `subs sp,sp,r0,LSL#4'
-[^:]*:25: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,LSR#3'
-[^:]*:26: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,ASR#3'
-[^:]*:27: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,ROR#3'
+[^:]*:24: Error: shift value over 3 not allowed in thumb mode -- `subs sp,sp,r0,LSL ?#4'
+[^:]*:25: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,LSR ?#3'
+[^:]*:26: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,ASR ?#3'
+[^:]*:27: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,ROR ?#3'
 [^:]*:28: Error: only LSL shift allowed in thumb mode -- `subs sp,sp,r0,RRX'
--- a/gas/testsuite/gas/arm/arch7em-bad.l
+++ b/gas/testsuite/gas/arm/arch7em-bad.l
@@ -3,10 +3,10 @@
 [^:]*:9: Error: selected processor does not support `pkhbt r9,r0,r0' in Thumb mode
 [^:]*:10: Error: selected processor does not support `pkhbt r0,r9,r0' in Thumb mode
 [^:]*:11: Error: selected processor does not support `pkhbt r0,r0,r9' in Thumb mode
-[^:]*:12: Error: selected processor does not support `pkhbt r0,r0,r0,lsl#0x14' in Thumb mode
-[^:]*:13: Error: selected processor does not support `pkhbt r0,r0,r0,lsl#3' in Thumb mode
+[^:]*:12: Error: selected processor does not support `pkhbt r0,r0,r0,lsl ?#0x14' in Thumb mode
+[^:]*:13: Error: selected processor does not support `pkhbt r0,r0,r0,lsl ?#3' in Thumb mode
 [^:]*:14: Error: selected processor does not support `pkhtb r1,r2,r3' in Thumb mode
-[^:]*:15: Error: selected processor does not support `pkhtb r1,r2,r3,asr#0x11' in Thumb mode
+[^:]*:15: Error: selected processor does not support `pkhtb r1,r2,r3,asr ?#0x11' in Thumb mode
 [^:]*:18: Error: selected processor does not support `qadd r1,r2,r3' in Thumb mode
 [^:]*:19: Error: selected processor does not support `qadd16 r1,r2,r3' in Thumb mode
 [^:]*:20: Error: selected processor does not support `qadd8 r1,r2,r3' in Thumb mode
@@ -121,10 +121,10 @@
 [^:]*:143: Error: selected processor does not support `uxtb16 r1,r2' in Thumb mode
 [^:]*:144: Error: selected processor does not support `uxtb16 r8,r9' in Thumb mode
 [^:]*:147: Error: selected processor does not support `sxtab r0,r0,r0' in Thumb mode
-[^:]*:148: Error: selected processor does not support `sxtab r0,r0,r0,ror#0' in Thumb mode
-[^:]*:149: Error: selected processor does not support `sxtab r9,r0,r0,ror#8' in Thumb mode
-[^:]*:150: Error: selected processor does not support `sxtab r0,r9,r0,ror#16' in Thumb mode
-[^:]*:151: Error: selected processor does not support `sxtab r0,r0,r9,ror#24' in Thumb mode
+[^:]*:148: Error: selected processor does not support `sxtab r0,r0,r0,ror ?#0' in Thumb mode
+[^:]*:149: Error: selected processor does not support `sxtab r9,r0,r0,ror ?#8' in Thumb mode
+[^:]*:150: Error: selected processor does not support `sxtab r0,r9,r0,ror ?#16' in Thumb mode
+[^:]*:151: Error: selected processor does not support `sxtab r0,r0,r9,ror ?#24' in Thumb mode
 [^:]*:153: Error: selected processor does not support `sxtab16 r1,r2,r3' in Thumb mode
 [^:]*:154: Error: selected processor does not support `sxtah r1,r2,r3' in Thumb mode
 [^:]*:155: Error: selected processor does not support `uxtab r1,r2,r3' in Thumb mode
--- a/gas/testsuite/gas/arm/mve-vldr-bad-1.l
+++ b/gas/testsuite/gas/arm/mve-vldr-bad-1.l
@@ -103,20 +103,20 @@
 [^:]*:88: Error: vector predicated instruction should be in VPT/VPST block -- `vldrdt.u64 q0,\[r0,q1\]'
 [^:]*:90: Error: instruction missing MVE vector predication code -- `vldrd.u64 q0,\[r0,q1\]'
 [^:]*:92: Error: shift expression expected -- `vldrb.u8 q0,\[r0,q1,#0\]'
-[^:]*:93: Error: can not shift offsets when accessing less than half-word -- `vldrb.u8 q0,\[r0,q1,UXTW#1\]'
-[^:]*:94: Error: can not shift offsets when accessing less than half-word -- `vldrb.u16 q0,\[r0,q1,UXTW#1\]'
-[^:]*:95: Error: can not shift offsets when accessing less than half-word -- `vldrb.u32 q0,\[r0,q1,UXTW#1\]'
+[^:]*:93: Error: can not shift offsets when accessing less than half-word -- `vldrb.u8 q0,\[r0,q1,UXTW ?#1\]'
+[^:]*:94: Error: can not shift offsets when accessing less than half-word -- `vldrb.u16 q0,\[r0,q1,UXTW ?#1\]'
+[^:]*:95: Error: can not shift offsets when accessing less than half-word -- `vldrb.u32 q0,\[r0,q1,UXTW ?#1\]'
 [^:]*:96: Error: shift expression expected -- `vldrh.u16 q0,\[r0,q1,#1\]'
-[^:]*:97: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u16 q0,\[r0,q1,UXTW#2\]'
-[^:]*:98: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u32 q0,\[r0,q1,UXTW#2\]'
-[^:]*:99: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u16 q0,\[r0,q1,UXTW#3\]'
-[^:]*:100: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u32 q0,\[r0,q1,UXTW#3\]'
+[^:]*:97: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u16 q0,\[r0,q1,UXTW ?#2\]'
+[^:]*:98: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u32 q0,\[r0,q1,UXTW ?#2\]'
+[^:]*:99: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u16 q0,\[r0,q1,UXTW ?#3\]'
+[^:]*:100: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrh.u32 q0,\[r0,q1,UXTW ?#3\]'
 [^:]*:101: Error: shift expression expected -- `vldrw.u32 q0,\[r0,q1,#2\]'
-[^:]*:102: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrw.u32 q0,\[r0,q1,UXTW#1\]'
-[^:]*:103: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrw.u32 q0,\[r0,q1,UXTW#3\]'
+[^:]*:102: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrw.u32 q0,\[r0,q1,UXTW ?#1\]'
+[^:]*:103: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrw.u32 q0,\[r0,q1,UXTW ?#3\]'
 [^:]*:104: Error: shift expression expected -- `vldrd.u64 q0,\[r0,q1,#3\]'
-[^:]*:105: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrd.u64 q0,\[r0,q1,UXTW#1\]'
-[^:]*:106: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrd.u64 q0,\[r0,q1,UXTW#2\]'
-[^:]*:107: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrd.u64 q0,\[r0,q1,UXTW#4\]'
+[^:]*:105: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrd.u64 q0,\[r0,q1,UXTW ?#1\]'
+[^:]*:106: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrd.u64 q0,\[r0,q1,UXTW ?#2\]'
+[^:]*:107: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vldrd.u64 q0,\[r0,q1,UXTW ?#4\]'
 
 
--- a/gas/testsuite/gas/arm/mve-vldr-bad-3.l
+++ b/gas/testsuite/gas/arm/mve-vldr-bad-3.l
@@ -161,27 +161,27 @@
 [^:]*:139: Error: bad element type for instruction -- `vldrb.p32 q0,\[r2,q3\]'
 [^:]*:139: Error: bad element type for instruction -- `vldrb.p64 q0,\[r2,q3\]'
 [^:]*:139: Error: bad element type for instruction -- `vldrb.s8 q0,\[r2,q3\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.8 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.32 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.64 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.f32 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.f64 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.p32 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.p64 q0,\[r2,q3,uxtw#1\]'
-[^:]*:142: Error: bad element type for instruction -- `vldrh.s16 q0,\[r2,q3,uxtw#1\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.8 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.16 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.64 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.f16 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.f64 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.p16 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.p64 q0,\[r2,q3,uxtw#2\]'
-[^:]*:145: Error: bad element type for instruction -- `vldrw.s32 q0,\[r2,q3,uxtw#2\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.8 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.16 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.32 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.f16 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.f32 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.p16 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.p32 q0,\[r2,q3,uxtw#3\]'
-[^:]*:148: Error: bad element type for instruction -- `vldrd.s64 q0,\[r2,q3,uxtw#3\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.8 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.32 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.64 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.f32 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.f64 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.p32 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.p64 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:142: Error: bad element type for instruction -- `vldrh.s16 q0,\[r2,q3,uxtw ?#1\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.8 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.16 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.64 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.f16 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.f64 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.p16 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.p64 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:145: Error: bad element type for instruction -- `vldrw.s32 q0,\[r2,q3,uxtw ?#2\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.8 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.16 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.32 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.f16 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.f32 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.p16 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.p32 q0,\[r2,q3,uxtw ?#3\]'
+[^:]*:148: Error: bad element type for instruction -- `vldrd.s64 q0,\[r2,q3,uxtw ?#3\]'
--- a/gas/testsuite/gas/arm/mve-vstr-bad-1.l
+++ b/gas/testsuite/gas/arm/mve-vstr-bad-1.l
@@ -45,7 +45,7 @@
 [^:]*:4: Warning: instruction is UNPREDICTABLE in an IT block
 [^:]*:36: *Info: macro .*
 [^:]*:39: Error: shift expression expected -- `vstrh.16 q0,\[r0,q1,#1\]'
-[^:]*:40: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrh.16 q0,\[r0,q1,UXTW#2\]'
+[^:]*:40: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrh.16 q0,\[r0,q1,UXTW ?#2\]'
 [^:]*:41: Error: bad element type for instruction -- `vstrw.8 q0,\[r0,q1\]'
 [^:]*:42: Error: bad element type for instruction -- `vstrw.u8 q0,\[r0,q1\]'
 [^:]*:43: Error: bad element type for instruction -- `vstrw.s8 q0,\[r0,q1\]'
@@ -71,8 +71,8 @@
 [^:]*:4: Warning: instruction is UNPREDICTABLE in an IT block
 [^:]*:53: *Info: macro .*
 [^:]*:56: Error: shift expression expected -- `vstrw.32 q0,\[r0,q1,#2\]'
-[^:]*:57: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrw.32 q0,\[r0,q1,UXTW#1\]'
-[^:]*:58: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrw.32 q0,\[r0,q1,UXTW#3\]'
+[^:]*:57: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrw.32 q0,\[r0,q1,UXTW ?#1\]'
+[^:]*:58: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrw.32 q0,\[r0,q1,UXTW ?#3\]'
 [^:]*:59: Error: bad element type for instruction -- `vstrd.8 q0,\[r0,q1\]'
 [^:]*:60: Error: bad element type for instruction -- `vstrd.u8 q0,\[r0,q1\]'
 [^:]*:61: Error: bad element type for instruction -- `vstrd.s8 q0,\[r0,q1\]'
@@ -100,9 +100,9 @@
 [^:]*:77: Warning: instruction is UNPREDICTABLE in an IT block
 [^:]*:83: *Info: macro .*
 [^:]*:84: Error: shift expression expected -- `vstrd.64 q0,\[r0,q1,#3\]'
-[^:]*:85: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrd.64 q0,\[r0,q1,UXTW#1\]'
-[^:]*:86: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrd.64 q0,\[r0,q1,UXTW#2\]'
-[^:]*:87: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrd.64 q0,\[r0,q1,UXTW#4\]'
+[^:]*:85: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrd.64 q0,\[r0,q1,UXTW ?#1\]'
+[^:]*:86: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrd.64 q0,\[r0,q1,UXTW ?#2\]'
+[^:]*:87: Error: shift immediate must be 1, 2 or 3 for half-word, word or double-word accesses respectively -- `vstrd.64 q0,\[r0,q1,UXTW ?#4\]'
 [^:]*:90: Error: syntax error -- `vstrbeq.32 q0,\[r0,q1\]'
 [^:]*:91: Error: syntax error -- `vstrbeq.32 q0,\[r0,q1\]'
 [^:]*:93: Error: syntax error -- `vstrbeq.32 q0,\[r0,q1\]'
--- a/gas/testsuite/gas/arm/neon-ldst-align-bad.l
+++ b/gas/testsuite/gas/arm/neon-ldst-align-bad.l
@@ -1,3 +1,3 @@
 [^:]*: Assembler messages:
-[^:]*:1: Error: bad alignment -- `vld1.8 {d0},\[r0:128\]'
-[^:]*:2: Error: bad alignment -- `vld1.8 {q0},\[r0:256\]'
+[^:]*:1: Error: bad alignment -- `vld1.8 {d0},\[r0 ?:128\]'
+[^:]*:2: Error: bad alignment -- `vld1.8 {q0},\[r0 ?:256\]'
--- a/gas/testsuite/gas/arm/shift-bad.l
+++ b/gas/testsuite/gas/arm/shift-bad.l
@@ -1,9 +1,9 @@
 .*shift-bad.s: Assembler messages:
-.*shift-bad.s:2: Error: extraneous shift as part of operand to shift insn -- `asr r0,r1,r2,ror#5'
+.*shift-bad.s:2: Error: extraneous shift as part of operand to shift insn -- `asr r0,r1,r2,ror ?#5'
 .*shift-bad.s:3: Error: extraneous shift as part of operand to shift insn -- `ror r0,r1,r2,lsl r3'
-.*shift-bad.s:7: Error: extraneous shift as part of operand to shift insn -- `ror r0,r0,r2,lsl#1'
-.*shift-bad.s:8: Error: extraneous shift as part of operand to shift insn -- `lsl r0,r0,r2,lsl#1'
+.*shift-bad.s:7: Error: extraneous shift as part of operand to shift insn -- `ror r0,r0,r2,lsl ?#1'
+.*shift-bad.s:8: Error: extraneous shift as part of operand to shift insn -- `lsl r0,r0,r2,lsl ?#1'
 .*shift-bad.s:9: Error: extraneous shift as part of operand to shift insn -- `lsl r0,r0,r2,asr r0'
-.*shift-bad.s:13: Error: extraneous shift as part of operand to shift insn -- `ror r0,r1,r2,lsl#1'
-.*shift-bad.s:14: Error: extraneous shift as part of operand to shift insn -- `lsl r0,r1,r2,lsl#1'
+.*shift-bad.s:13: Error: extraneous shift as part of operand to shift insn -- `ror r0,r1,r2,lsl ?#1'
+.*shift-bad.s:14: Error: extraneous shift as part of operand to shift insn -- `lsl r0,r1,r2,lsl ?#1'
 .*shift-bad.s:15: Error: extraneous shift as part of operand to shift insn -- `lsl r0,r1,r2,asr r0'
--- a/gas/testsuite/gas/arm/sp-pc-validations-bad-t-v8a.l
+++ b/gas/testsuite/gas/arm/sp-pc-validations-bad-t-v8a.l
@@ -131,7 +131,7 @@
 [^:]*:12: IT blocks containing more than one conditional instruction are performance deprecated in ARMv8-A and ARMv8-R
 [^:]*:21: *Info: macro .*
 [^:]*:45: *Info: macro .*
-[^:]*:12: Error: branch must be last instruction in IT block -- `ldreq.w r15,\[r0,r1,LSL#2\]'
+[^:]*:12: Error: branch must be last instruction in IT block -- `ldreq.w r15,\[r0,r1,LSL ?#2\]'
 [^:]*:21: *Info: macro .*
 [^:]*:45: *Info: macro .*
 [^:]*:48: Error: r15 not allowed here -- `ldrb pc,\[r0,#4\]'
@@ -144,8 +144,8 @@
 [^:]*:66: Error: r15 not allowed here -- `ldrb pc,\[r0,r1\]'
 [^:]*:67: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[pc,r1\]'
 [^:]*:68: Error: r15 not allowed here -- `ldrb r0,\[r1,pc\]'
-[^:]*:69: Error: r15 not allowed here -- `ldrb.w pc,\[r0,r1,LSL#1\]'
-[^:]*:71: Error: r15 not allowed here -- `ldrb.w r2,\[r0,pc,LSL#2\]'
+[^:]*:69: Error: r15 not allowed here -- `ldrb.w pc,\[r0,r1,LSL ?#1\]'
+[^:]*:71: Error: r15 not allowed here -- `ldrb.w r2,\[r0,pc,LSL ?#2\]'
 [^:]*:75: Error: r15 not allowed here -- `ldrbt pc,\[r0,#4\]'
 [^:]*:79: Error: r15 not allowed here -- `ldrd pc,r0,\[r1\]'
 [^:]*:81: Error: r12 not allowed here -- `ldrd r12,\[r1\]'
@@ -184,8 +184,8 @@
 [^:]*:149: Error: r15 not allowed here -- `ldrh pc,\[r0,r1\]'
 [^:]*:150: Error: cannot use register index with PC-relative addressing -- `ldrh r0,\[pc,r1\]'
 [^:]*:151: Error: r15 not allowed here -- `ldrh r0,\[r1,pc\]'
-[^:]*:152: Error: r15 not allowed here -- `ldrh.w pc,\[r0,r1,LSL#1\]'
-[^:]*:154: Error: r15 not allowed here -- `ldrh.w r2,\[r0,pc,LSL#1\]'
+[^:]*:152: Error: r15 not allowed here -- `ldrh.w pc,\[r0,r1,LSL ?#1\]'
+[^:]*:154: Error: r15 not allowed here -- `ldrh.w r2,\[r0,pc,LSL ?#1\]'
 [^:]*:158: Error: r15 not allowed here -- `ldrht pc,\[r0,#4\]'
 [^:]*:162: Error: r15 not allowed here -- `ldrsb pc,\[r0,#4\]'
 [^:]*:165: Error: r15 not allowed here -- `ldrsb pc,\[r0,#-4\]'
@@ -196,8 +196,8 @@
 [^:]*:179: Error: r15 not allowed here -- `ldrsb pc,\[r0,r1\]'
 [^:]*:180: Error: cannot use register index with PC-relative addressing -- `ldrsb r0,\[pc,r1\]'
 [^:]*:181: Error: r15 not allowed here -- `ldrsb r0,\[r1,pc\]'
-[^:]*:182: Error: r15 not allowed here -- `ldrsb.w pc,\[r0,r1,LSL#2\]'
-[^:]*:185: Error: r15 not allowed here -- `ldrsb.w r2,\[r0,pc,LSL#2\]'
+[^:]*:182: Error: r15 not allowed here -- `ldrsb.w pc,\[r0,r1,LSL ?#2\]'
+[^:]*:185: Error: r15 not allowed here -- `ldrsb.w r2,\[r0,pc,LSL ?#2\]'
 [^:]*:190: Error: r15 not allowed here -- `ldrsbt pc,\[r0,#4\]'
 [^:]*:195: Error: r15 not allowed here -- `ldrsh pc,\[r0,#4\]'
 [^:]*:197: Error: r15 not allowed here -- `ldrsh pc,\[r0,#-4\]'
@@ -207,8 +207,8 @@
 [^:]*:210: Error: r15 not allowed here -- `ldrsh pc,\[r0,r1\]'
 [^:]*:211: Error: cannot use register index with PC-relative addressing -- `ldrsh r0,\[pc,r1\]'
 [^:]*:212: Error: r15 not allowed here -- `ldrsh r0,\[r1,pc\]'
-[^:]*:214: Error: r15 not allowed here -- `ldrsh.w pc,\[r0,r1,LSL#3\]'
-[^:]*:217: Error: r15 not allowed here -- `ldrsh.w r0,\[r1,pc,LSL#3\]'
+[^:]*:214: Error: r15 not allowed here -- `ldrsh.w pc,\[r0,r1,LSL ?#3\]'
+[^:]*:217: Error: r15 not allowed here -- `ldrsh.w r0,\[r1,pc,LSL ?#3\]'
 [^:]*:221: Error: r15 not allowed here -- `ldrsht pc,\[r0,#4\]'
 [^:]*:226: Error: r15 not allowed here -- `ldrt pc,\[r0,#4\]'
 [^:]*:232: Error: r15 not allowed here -- `str pc,\[r0,#4\]'
@@ -217,7 +217,7 @@
 [^:]*:235: Error: cannot use post-indexing with PC-relative addressing -- `str r0,\[pc\],#4'
 [^:]*:236: Error: cannot use writeback with PC-relative addressing -- `str r0,\[pc,#4\]!'
 [^:]*:239: Error: cannot use register index with PC-relative addressing -- `str.w r0,\[pc,r1\]'
-[^:]*:240: Error: cannot use register index with PC-relative addressing -- `str.w r0,\[pc,r1,LSL#2\]'
+[^:]*:240: Error: cannot use register index with PC-relative addressing -- `str.w r0,\[pc,r1,LSL ?#2\]'
 [^:]*:246: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,#4\]'
 [^:]*:247: Error: r15 not allowed here -- `strb.w pc,\[r0,#4\]'
 [^:]*:249: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc,#-4\]'
@@ -227,11 +227,11 @@
 [^:]*:253: Error: r15 not allowed here -- `strb pc,\[r0\],#4'
 [^:]*:254: Error: r15 not allowed here -- `strb pc,\[r0,#4\]!'
 [^:]*:260: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,r1\]'
-[^:]*:261: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,r1,LSL#2\]'
+[^:]*:261: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,r1,LSL ?#2\]'
 [^:]*:262: Error: r15 not allowed here -- `strb.w pc,\[r0,r1\]'
-[^:]*:263: Error: r15 not allowed here -- `strb.w pc,\[r0,r1,LSL#2\]'
+[^:]*:263: Error: r15 not allowed here -- `strb.w pc,\[r0,r1,LSL ?#2\]'
 [^:]*:266: Error: r15 not allowed here -- `strb.w r0,\[r1,pc\]'
-[^:]*:267: Error: r15 not allowed here -- `strb.w r0,\[r1,pc,LSL#2\]'
+[^:]*:267: Error: r15 not allowed here -- `strb.w r0,\[r1,pc,LSL ?#2\]'
 [^:]*:272: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[pc,#4\]'
 [^:]*:273: Error: r15 not allowed here -- `strbt pc,\[r0,#4\]'
 [^:]*:277: Error: cannot use register index with PC-relative addressing -- `strd r0,r1,\[pc,#4\]'
@@ -265,7 +265,7 @@
 [^:]*:335: Error: cannot use post-indexing with PC-relative addressing -- `strh r0,\[pc\],#4'
 [^:]*:336: Error: cannot use writeback with PC-relative addressing -- `strh r0,\[pc,#4\]!'
 [^:]*:339: Error: cannot use register index with PC-relative addressing -- `strh.w r0,\[pc,r1\]'
-[^:]*:340: Error: cannot use register index with PC-relative addressing -- `strh.w r0,\[pc,r1,LSL#2\]'
+[^:]*:340: Error: cannot use register index with PC-relative addressing -- `strh.w r0,\[pc,r1,LSL ?#2\]'
 [^:]*:341: Error: r15 not allowed here -- `strh.w pc,\[r0,#4\]'
 [^:]*:342: Error: r15 not allowed here -- `strh.w pc,\[r0\]'
 [^:]*:345: Error: r15 not allowed here -- `strh pc,\[r0,#-4\]'
@@ -273,8 +273,8 @@
 [^:]*:347: Error: r15 not allowed here -- `strh pc,\[r0,#4\]!'
 [^:]*:351: Error: r15 not allowed here -- `strh.w pc,\[r0,r1\]'
 [^:]*:353: Error: r15 not allowed here -- `strh.w r0,\[r1,pc\]'
-[^:]*:355: Error: r15 not allowed here -- `strh.w pc,\[r0,r1,LSL#2\]'
-[^:]*:357: Error: r15 not allowed here -- `strh.w r0,\[r1,pc,LSL#2\]'
+[^:]*:355: Error: r15 not allowed here -- `strh.w pc,\[r0,r1,LSL ?#2\]'
+[^:]*:357: Error: r15 not allowed here -- `strh.w r0,\[r1,pc,LSL ?#2\]'
 [^:]*:361: Error: cannot use register index with PC-relative addressing -- `strht r0,\[pc,#4\]'
 [^:]*:362: Error: r15 not allowed here -- `strht pc,\[r0,#4\]'
 [^:]*:363: Error: cannot use register index with PC-relative addressing -- `strht sp,\[pc,#4\]'
--- a/gas/testsuite/gas/arm/sp-pc-validations-bad-t.l
+++ b/gas/testsuite/gas/arm/sp-pc-validations-bad-t.l
@@ -41,7 +41,7 @@
 [^:]*:12: Error: branch must be last instruction in IT block -- `ldreq.w r15,\[r0,r1\]'
 [^:]*:21: *Info: macro .*
 [^:]*:44: *Info: macro .*
-[^:]*:12: Error: branch must be last instruction in IT block -- `ldreq.w r15,\[r0,r1,LSL#2\]'
+[^:]*:12: Error: branch must be last instruction in IT block -- `ldreq.w r15,\[r0,r1,LSL ?#2\]'
 [^:]*:21: *Info: macro .*
 [^:]*:45: *Info: macro .*
 [^:]*:48: Error: r15 not allowed here -- `ldrb pc,\[r0,#4\]'
@@ -59,10 +59,10 @@
 [^:]*:66: Error: r15 not allowed here -- `ldrb pc,\[r0,r1\]'
 [^:]*:67: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[pc,r1\]'
 [^:]*:68: Error: r15 not allowed here -- `ldrb r0,\[r1,pc\]'
-[^:]*:69: Error: r15 not allowed here -- `ldrb.w pc,\[r0,r1,LSL#1\]'
+[^:]*:69: Error: r15 not allowed here -- `ldrb.w pc,\[r0,r1,LSL ?#1\]'
 [^:]*:70: Error: r13 not allowed here -- `ldrb.w sp,\[r0,r1\]'
-[^:]*:71: Error: r15 not allowed here -- `ldrb.w r2,\[r0,pc,LSL#2\]'
-[^:]*:72: Error: r13 not allowed here -- `ldrb.w r2,\[r0,sp,LSL#2\]'
+[^:]*:71: Error: r15 not allowed here -- `ldrb.w r2,\[r0,pc,LSL ?#2\]'
+[^:]*:72: Error: r13 not allowed here -- `ldrb.w r2,\[r0,sp,LSL ?#2\]'
 [^:]*:75: Error: r15 not allowed here -- `ldrbt pc,\[r0,#4\]'
 [^:]*:76: Error: r13 not allowed here -- `ldrbt sp,\[r0,#4\]'
 [^:]*:79: Error: r15 not allowed here -- `ldrd pc,r0,\[r1\]'
@@ -123,10 +123,10 @@
 [^:]*:149: Error: r15 not allowed here -- `ldrh pc,\[r0,r1\]'
 [^:]*:150: Error: cannot use register index with PC-relative addressing -- `ldrh r0,\[pc,r1\]'
 [^:]*:151: Error: r15 not allowed here -- `ldrh r0,\[r1,pc\]'
-[^:]*:152: Error: r15 not allowed here -- `ldrh.w pc,\[r0,r1,LSL#1\]'
-[^:]*:153: Error: r13 not allowed here -- `ldrh.w sp,\[r0,r1,LSL#1\]'
-[^:]*:154: Error: r15 not allowed here -- `ldrh.w r2,\[r0,pc,LSL#1\]'
-[^:]*:155: Error: r13 not allowed here -- `ldrh.w r2,\[r0,sp,LSL#1\]'
+[^:]*:152: Error: r15 not allowed here -- `ldrh.w pc,\[r0,r1,LSL ?#1\]'
+[^:]*:153: Error: r13 not allowed here -- `ldrh.w sp,\[r0,r1,LSL ?#1\]'
+[^:]*:154: Error: r15 not allowed here -- `ldrh.w r2,\[r0,pc,LSL ?#1\]'
+[^:]*:155: Error: r13 not allowed here -- `ldrh.w r2,\[r0,sp,LSL ?#1\]'
 [^:]*:158: Error: r15 not allowed here -- `ldrht pc,\[r0,#4\]'
 [^:]*:159: Error: r13 not allowed here -- `ldrht sp,\[r0,#4\]'
 [^:]*:162: Error: r15 not allowed here -- `ldrsb pc,\[r0,#4\]'
@@ -144,10 +144,10 @@
 [^:]*:179: Error: r15 not allowed here -- `ldrsb pc,\[r0,r1\]'
 [^:]*:180: Error: cannot use register index with PC-relative addressing -- `ldrsb r0,\[pc,r1\]'
 [^:]*:181: Error: r15 not allowed here -- `ldrsb r0,\[r1,pc\]'
-[^:]*:182: Error: r15 not allowed here -- `ldrsb.w pc,\[r0,r1,LSL#2\]'
-[^:]*:184: Error: r13 not allowed here -- `ldrsb.w sp,\[r0,r1,LSL#2\]'
-[^:]*:185: Error: r15 not allowed here -- `ldrsb.w r2,\[r0,pc,LSL#2\]'
-[^:]*:186: Error: r13 not allowed here -- `ldrsb.w r2,\[r0,sp,LSL#2\]'
+[^:]*:182: Error: r15 not allowed here -- `ldrsb.w pc,\[r0,r1,LSL ?#2\]'
+[^:]*:184: Error: r13 not allowed here -- `ldrsb.w sp,\[r0,r1,LSL ?#2\]'
+[^:]*:185: Error: r15 not allowed here -- `ldrsb.w r2,\[r0,pc,LSL ?#2\]'
+[^:]*:186: Error: r13 not allowed here -- `ldrsb.w r2,\[r0,sp,LSL ?#2\]'
 [^:]*:190: Error: r15 not allowed here -- `ldrsbt pc,\[r0,#4\]'
 [^:]*:191: Error: r13 not allowed here -- `ldrsbt sp,\[r0,#4\]'
 [^:]*:195: Error: r15 not allowed here -- `ldrsh pc,\[r0,#4\]'
@@ -164,10 +164,10 @@
 [^:]*:210: Error: r15 not allowed here -- `ldrsh pc,\[r0,r1\]'
 [^:]*:211: Error: cannot use register index with PC-relative addressing -- `ldrsh r0,\[pc,r1\]'
 [^:]*:212: Error: r15 not allowed here -- `ldrsh r0,\[r1,pc\]'
-[^:]*:214: Error: r15 not allowed here -- `ldrsh.w pc,\[r0,r1,LSL#3\]'
-[^:]*:215: Error: r13 not allowed here -- `ldrsh.w sp,\[r0,r1,LSL#3\]'
-[^:]*:216: Error: r13 not allowed here -- `ldrsh.w r0,\[r1,sp,LSL#3\]'
-[^:]*:217: Error: r15 not allowed here -- `ldrsh.w r0,\[r1,pc,LSL#3\]'
+[^:]*:214: Error: r15 not allowed here -- `ldrsh.w pc,\[r0,r1,LSL ?#3\]'
+[^:]*:215: Error: r13 not allowed here -- `ldrsh.w sp,\[r0,r1,LSL ?#3\]'
+[^:]*:216: Error: r13 not allowed here -- `ldrsh.w r0,\[r1,sp,LSL ?#3\]'
+[^:]*:217: Error: r15 not allowed here -- `ldrsh.w r0,\[r1,pc,LSL ?#3\]'
 [^:]*:221: Error: r15 not allowed here -- `ldrsht pc,\[r0,#4\]'
 [^:]*:222: Error: r13 not allowed here -- `ldrsht sp,\[r0,#4\]'
 [^:]*:226: Error: r15 not allowed here -- `ldrt pc,\[r0,#4\]'
@@ -178,7 +178,7 @@
 [^:]*:235: Error: cannot use post-indexing with PC-relative addressing -- `str r0,\[pc\],#4'
 [^:]*:236: Error: cannot use writeback with PC-relative addressing -- `str r0,\[pc,#4\]!'
 [^:]*:239: Error: cannot use register index with PC-relative addressing -- `str.w r0,\[pc,r1\]'
-[^:]*:240: Error: cannot use register index with PC-relative addressing -- `str.w r0,\[pc,r1,LSL#2\]'
+[^:]*:240: Error: cannot use register index with PC-relative addressing -- `str.w r0,\[pc,r1,LSL ?#2\]'
 [^:]*:246: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,#4\]'
 [^:]*:247: Error: r15 not allowed here -- `strb.w pc,\[r0,#4\]'
 [^:]*:248: Error: r13 not allowed here -- `strb.w sp,\[r0,#4\]'
@@ -192,15 +192,15 @@
 [^:]*:256: Error: r13 not allowed here -- `strb sp,\[r0\],#4'
 [^:]*:257: Error: r13 not allowed here -- `strb sp,\[r0,#4\]!'
 [^:]*:260: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,r1\]'
-[^:]*:261: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,r1,LSL#2\]'
+[^:]*:261: Error: cannot use register index with PC-relative addressing -- `strb.w r0,\[pc,r1,LSL ?#2\]'
 [^:]*:262: Error: r15 not allowed here -- `strb.w pc,\[r0,r1\]'
-[^:]*:263: Error: r15 not allowed here -- `strb.w pc,\[r0,r1,LSL#2\]'
+[^:]*:263: Error: r15 not allowed here -- `strb.w pc,\[r0,r1,LSL ?#2\]'
 [^:]*:264: Error: r13 not allowed here -- `strb.w sp,\[r0,r1\]'
-[^:]*:265: Error: r13 not allowed here -- `strb.w sp,\[r0,r1,LSL#2\]'
+[^:]*:265: Error: r13 not allowed here -- `strb.w sp,\[r0,r1,LSL ?#2\]'
 [^:]*:266: Error: r15 not allowed here -- `strb.w r0,\[r1,pc\]'
-[^:]*:267: Error: r15 not allowed here -- `strb.w r0,\[r1,pc,LSL#2\]'
+[^:]*:267: Error: r15 not allowed here -- `strb.w r0,\[r1,pc,LSL ?#2\]'
 [^:]*:268: Error: r13 not allowed here -- `strb.w r0,\[r1,sp\]'
-[^:]*:269: Error: r13 not allowed here -- `strb.w r0,\[r1,sp,LSL#2\]'
+[^:]*:269: Error: r13 not allowed here -- `strb.w r0,\[r1,sp,LSL ?#2\]'
 [^:]*:272: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[pc,#4\]'
 [^:]*:273: Error: r15 not allowed here -- `strbt pc,\[r0,#4\]'
 [^:]*:274: Error: r13 not allowed here -- `strbt sp,\[r0,#4\]'
@@ -252,7 +252,7 @@
 [^:]*:335: Error: cannot use post-indexing with PC-relative addressing -- `strh r0,\[pc\],#4'
 [^:]*:336: Error: cannot use writeback with PC-relative addressing -- `strh r0,\[pc,#4\]!'
 [^:]*:339: Error: cannot use register index with PC-relative addressing -- `strh.w r0,\[pc,r1\]'
-[^:]*:340: Error: cannot use register index with PC-relative addressing -- `strh.w r0,\[pc,r1,LSL#2\]'
+[^:]*:340: Error: cannot use register index with PC-relative addressing -- `strh.w r0,\[pc,r1,LSL ?#2\]'
 [^:]*:341: Error: r15 not allowed here -- `strh.w pc,\[r0,#4\]'
 [^:]*:342: Error: r15 not allowed here -- `strh.w pc,\[r0\]'
 [^:]*:343: Error: r13 not allowed here -- `strh.w sp,\[r0,#4\]'
@@ -267,10 +267,10 @@
 [^:]*:352: Error: r13 not allowed here -- `strh.w sp,\[r0,r1\]'
 [^:]*:353: Error: r15 not allowed here -- `strh.w r0,\[r1,pc\]'
 [^:]*:354: Error: r13 not allowed here -- `strh.w r0,\[r1,sp\]'
-[^:]*:355: Error: r15 not allowed here -- `strh.w pc,\[r0,r1,LSL#2\]'
-[^:]*:356: Error: r13 not allowed here -- `strh.w sp,\[r0,r1,LSL#2\]'
-[^:]*:357: Error: r15 not allowed here -- `strh.w r0,\[r1,pc,LSL#2\]'
-[^:]*:358: Error: r13 not allowed here -- `strh.w r0,\[r1,sp,LSL#2\]'
+[^:]*:355: Error: r15 not allowed here -- `strh.w pc,\[r0,r1,LSL ?#2\]'
+[^:]*:356: Error: r13 not allowed here -- `strh.w sp,\[r0,r1,LSL ?#2\]'
+[^:]*:357: Error: r15 not allowed here -- `strh.w r0,\[r1,pc,LSL ?#2\]'
+[^:]*:358: Error: r13 not allowed here -- `strh.w r0,\[r1,sp,LSL ?#2\]'
 [^:]*:361: Error: cannot use register index with PC-relative addressing -- `strht r0,\[pc,#4\]'
 [^:]*:362: Error: r15 not allowed here -- `strht pc,\[r0,#4\]'
 [^:]*:363: Error: r13 not allowed here -- `strht sp,\[pc,#4\]'
--- a/gas/testsuite/gas/arm/sp-pc-validations-bad.l
+++ b/gas/testsuite/gas/arm/sp-pc-validations-bad.l
@@ -1,27 +1,27 @@
 [^:]*: Assembler messages:
-[^:]*:11: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[r1,pc,LSL#2\]'
-[^:]*:12: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[r1,pc,LSL#2\]!'
-[^:]*:13: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[r1\],pc,LSL#2'
-[^:]*:14: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[pc,r1,LSL#2\]!'
-[^:]*:15: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[pc\],r1,LSL#2'
+[^:]*:11: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[r1,pc,LSL ?#2\]'
+[^:]*:12: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[r1,pc,LSL ?#2\]!'
+[^:]*:13: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[r1\],pc,LSL ?#2'
+[^:]*:14: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[pc,r1,LSL ?#2\]!'
+[^:]*:15: Error: cannot use register index with PC-relative addressing -- `ldr r0,\[pc\],r1,LSL ?#2'
 [^:]*:18: Error: r15 not allowed here -- `ldrb pc,\[r0,#4\]'
 [^:]*:19: Error: r15 not allowed here -- `ldrb pc,\[r0\],#4'
 [^:]*:20: Error: r15 not allowed here -- `ldrb pc,\[r0,#4\]!'
 [^:]*:23: Error: r15 not allowed here -- `ldrb pc,label'
 [^:]*:24: Error: r15 not allowed here -- `ldrb pc,\[pc,#-0\]'
-[^:]*:27: Error: r15 not allowed here -- `ldrb pc,\[r0,r1,LSL#2\]'
-[^:]*:28: Error: r15 not allowed here -- `ldrb pc,\[r0,r1,LSL#2\]!'
-[^:]*:29: Error: r15 not allowed here -- `ldrb pc,\[r0\],r1,LSL#2'
-[^:]*:30: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[r1,pc,LSL#2\]'
-[^:]*:31: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[r1,pc,LSL#2\]!'
-[^:]*:32: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[r1\],pc,LSL#2'
-[^:]*:33: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[pc,r1,LSL#2\]!'
-[^:]*:34: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[pc\],r1,LSL#2'
+[^:]*:27: Error: r15 not allowed here -- `ldrb pc,\[r0,r1,LSL ?#2\]'
+[^:]*:28: Error: r15 not allowed here -- `ldrb pc,\[r0,r1,LSL ?#2\]!'
+[^:]*:29: Error: r15 not allowed here -- `ldrb pc,\[r0\],r1,LSL ?#2'
+[^:]*:30: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[r1,pc,LSL ?#2\]'
+[^:]*:31: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[r1,pc,LSL ?#2\]!'
+[^:]*:32: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[r1\],pc,LSL ?#2'
+[^:]*:33: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[pc,r1,LSL ?#2\]!'
+[^:]*:34: Error: cannot use register index with PC-relative addressing -- `ldrb r0,\[pc\],r1,LSL ?#2'
 [^:]*:37: Error: r15 not allowed here -- `ldrbt pc,\[r0\],#4'
 [^:]*:38: Error: cannot use register index with PC-relative addressing -- `ldrbt r0,\[pc\],#4'
-[^:]*:39: Error: r15 not allowed here -- `ldrbt pc,\[r0\],r1,LSL#4'
-[^:]*:40: Error: cannot use register index with PC-relative addressing -- `ldrbt r0,\[pc\],r1,LSL#4'
-[^:]*:41: Error: cannot use register index with PC-relative addressing -- `ldrbt r0,\[r1\],pc,LSL#4'
+[^:]*:39: Error: r15 not allowed here -- `ldrbt pc,\[r0\],r1,LSL ?#4'
+[^:]*:40: Error: cannot use register index with PC-relative addressing -- `ldrbt r0,\[pc\],r1,LSL ?#4'
+[^:]*:41: Error: cannot use register index with PC-relative addressing -- `ldrbt r0,\[r1\],pc,LSL ?#4'
 [^:]*:44: Error: r15 not allowed here -- `ldrd r0,pc,\[r1,#4\]'
 [^:]*:45: Error: r15 not allowed here -- `ldrd r0,pc,\[r1\],#4'
 [^:]*:46: Error: r15 not allowed here -- `ldrd r0,pc,\[r1,#4\]!'
@@ -98,32 +98,32 @@
 [^:]*:153: Error: cannot use register index with PC-relative addressing -- `ldrsht r0,\[r1\],pc'
 [^:]*:156: Error: r15 not allowed here -- `ldrt pc,\[r0\],#4'
 [^:]*:157: Error: cannot use register index with PC-relative addressing -- `ldrt r0,\[pc\],#4'
-[^:]*:158: Error: r15 not allowed here -- `ldrt pc,\[r0\],r1,LSL#4'
-[^:]*:159: Error: cannot use register index with PC-relative addressing -- `ldrt r0,\[pc\],r1,LSL#4'
-[^:]*:160: Error: cannot use register index with PC-relative addressing -- `ldrt r0,\[r1\],pc,LSL#4'
+[^:]*:158: Error: r15 not allowed here -- `ldrt pc,\[r0\],r1,LSL ?#4'
+[^:]*:159: Error: cannot use register index with PC-relative addressing -- `ldrt r0,\[pc\],r1,LSL ?#4'
+[^:]*:160: Error: cannot use register index with PC-relative addressing -- `ldrt r0,\[r1\],pc,LSL ?#4'
 [^:]*:166: Error: cannot use register index with PC-relative addressing -- `str r0,\[pc\],#4'
 [^:]*:167: Error: cannot use register index with PC-relative addressing -- `str r0,\[pc,#4\]!'
-[^:]*:170: Error: cannot use register index with PC-relative addressing -- `str r0,\[r1,pc,LSL#4\]'
-[^:]*:171: Error: cannot use register index with PC-relative addressing -- `str r0,\[r1,pc,LSL#4\]!'
-[^:]*:172: Error: cannot use register index with PC-relative addressing -- `str r0,\[r1\],pc,LSL#4'
+[^:]*:170: Error: cannot use register index with PC-relative addressing -- `str r0,\[r1,pc,LSL ?#4\]'
+[^:]*:171: Error: cannot use register index with PC-relative addressing -- `str r0,\[r1,pc,LSL ?#4\]!'
+[^:]*:172: Error: cannot use register index with PC-relative addressing -- `str r0,\[r1\],pc,LSL ?#4'
 [^:]*:175: Error: r15 not allowed here -- `strb pc,\[r0,#4\]'
 [^:]*:176: Error: r15 not allowed here -- `strb pc,\[r0\],#4'
 [^:]*:177: Error: r15 not allowed here -- `strb pc,\[r0,#4\]!'
 [^:]*:178: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc\],#4'
 [^:]*:179: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc,#4\]!'
-[^:]*:182: Error: r15 not allowed here -- `strb pc,\[r0,r1,LSL#4\]'
-[^:]*:183: Error: r15 not allowed here -- `strb pc,\[r0,r1,LSL#4\]!'
-[^:]*:184: Error: r15 not allowed here -- `strb pc,\[r0\],r1,LSL#4'
-[^:]*:185: Error: cannot use register index with PC-relative addressing -- `strb r1,\[r0,pc,LSL#4\]'
-[^:]*:186: Error: cannot use register index with PC-relative addressing -- `strb r1,\[r0,pc,LSL#4\]!'
-[^:]*:187: Error: cannot use register index with PC-relative addressing -- `strb r1,\[r0\],pc,LSL#4'
-[^:]*:188: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc,r1,LSL#4\]!'
-[^:]*:189: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc\],r1,LSL#4'
+[^:]*:182: Error: r15 not allowed here -- `strb pc,\[r0,r1,LSL ?#4\]'
+[^:]*:183: Error: r15 not allowed here -- `strb pc,\[r0,r1,LSL ?#4\]!'
+[^:]*:184: Error: r15 not allowed here -- `strb pc,\[r0\],r1,LSL ?#4'
+[^:]*:185: Error: cannot use register index with PC-relative addressing -- `strb r1,\[r0,pc,LSL ?#4\]'
+[^:]*:186: Error: cannot use register index with PC-relative addressing -- `strb r1,\[r0,pc,LSL ?#4\]!'
+[^:]*:187: Error: cannot use register index with PC-relative addressing -- `strb r1,\[r0\],pc,LSL ?#4'
+[^:]*:188: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc,r1,LSL ?#4\]!'
+[^:]*:189: Error: cannot use register index with PC-relative addressing -- `strb r0,\[pc\],r1,LSL ?#4'
 [^:]*:192: Error: r15 not allowed here -- `strbt pc,\[r0\],#4'
 [^:]*:193: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[pc\],#4'
-[^:]*:194: Error: r15 not allowed here -- `strbt pc,\[r0\],r1,LSL#4'
-[^:]*:195: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[pc\],r1,LSL#4'
-[^:]*:196: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[r1\],pc,LSL#4'
+[^:]*:194: Error: r15 not allowed here -- `strbt pc,\[r0\],r1,LSL ?#4'
+[^:]*:195: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[pc\],r1,LSL ?#4'
+[^:]*:196: Error: cannot use register index with PC-relative addressing -- `strbt r0,\[r1\],pc,LSL ?#4'
 [^:]*:199: Error: r15 not allowed here -- `strd r0,pc,\[r1,#4\]'
 [^:]*:200: Error: r15 not allowed here -- `strd r0,pc,\[r1\],#4'
 [^:]*:201: Error: r15 not allowed here -- `strd r0,pc,\[r1,#4\]!'
@@ -167,5 +167,5 @@
 [^:]*:255: Error: cannot use register index with PC-relative addressing -- `strht r0,\[pc\],r1'
 [^:]*:256: Error: cannot use register index with PC-relative addressing -- `strht r0,\[r1\],pc'
 [^:]*:259: Error: cannot use register index with PC-relative addressing -- `strt r0,\[pc\],#4'
-[^:]*:260: Error: cannot use register index with PC-relative addressing -- `strt r0,\[pc\],r1,LSL#4'
-[^:]*:261: Error: cannot use register index with PC-relative addressing -- `strt r0,\[r1\],pc,LSL#4'
+[^:]*:260: Error: cannot use register index with PC-relative addressing -- `strt r0,\[pc\],r1,LSL ?#4'
+[^:]*:261: Error: cannot use register index with PC-relative addressing -- `strt r0,\[r1\],pc,LSL ?#4'
--- a/gas/testsuite/gas/arm/t16-bad.l
+++ b/gas/testsuite/gas/arm/t16-bad.l
@@ -7,7 +7,7 @@
 [^:]*:36: *Info: macro .*
 [^:]*:16: Error: unshifted register required -- `tst r0,#12'
 [^:]*:36: *Info: macro .*
-[^:]*:17: Error: unshifted register required -- `tst r0,r1,lsl#2'
+[^:]*:17: Error: unshifted register required -- `tst r0,r1,lsl ?#2'
 [^:]*:36: *Info: macro .*
 [^:]*:18: Error: unshifted register required -- `tst r0,r1,lsl r3'
 [^:]*:36: *Info: macro .*
@@ -19,7 +19,7 @@
 [^:]*:37: *Info: macro .*
 [^:]*:16: Error: unshifted register required -- `cmn r0,#12'
 [^:]*:37: *Info: macro .*
-[^:]*:17: Error: unshifted register required -- `cmn r0,r1,lsl#2'
+[^:]*:17: Error: unshifted register required -- `cmn r0,r1,lsl ?#2'
 [^:]*:37: *Info: macro .*
 [^:]*:18: Error: unshifted register required -- `cmn r0,r1,lsl r3'
 [^:]*:37: *Info: macro .*
@@ -31,7 +31,7 @@
 [^:]*:38: *Info: macro .*
 [^:]*:16: Error: unshifted register required -- `mvn r0,#12'
 [^:]*:38: *Info: macro .*
-[^:]*:17: Error: unshifted register required -- `mvn r0,r1,lsl#2'
+[^:]*:17: Error: unshifted register required -- `mvn r0,r1,lsl ?#2'
 [^:]*:38: *Info: macro .*
 [^:]*:18: Error: unshifted register required -- `mvn r0,r1,lsl r3'
 [^:]*:38: *Info: macro .*
@@ -57,7 +57,7 @@
 [^:]*:12: Error: lo register required -- `sxtb r0,r8'
 [^:]*:21: *Info: macro .*
 [^:]*:43: *Info: macro .*
-[^:]*:22: Error: Thumb encoding does not support rotation -- `sxtb r0,r1,ror#8'
+[^:]*:22: Error: Thumb encoding does not support rotation -- `sxtb r0,r1,ror ?#8'
 [^:]*:43: *Info: macro .*
 [^:]*:11: Error: lo register required -- `sxth r8,r0'
 [^:]*:21: *Info: macro .*
@@ -65,7 +65,7 @@
 [^:]*:12: Error: lo register required -- `sxth r0,r8'
 [^:]*:21: *Info: macro .*
 [^:]*:44: *Info: macro .*
-[^:]*:22: Error: Thumb encoding does not support rotation -- `sxth r0,r1,ror#8'
+[^:]*:22: Error: Thumb encoding does not support rotation -- `sxth r0,r1,ror ?#8'
 [^:]*:44: *Info: macro .*
 [^:]*:11: Error: lo register required -- `uxtb r8,r0'
 [^:]*:21: *Info: macro .*
@@ -73,7 +73,7 @@
 [^:]*:12: Error: lo register required -- `uxtb r0,r8'
 [^:]*:21: *Info: macro .*
 [^:]*:45: *Info: macro .*
-[^:]*:22: Error: Thumb encoding does not support rotation -- `uxtb r0,r1,ror#8'
+[^:]*:22: Error: Thumb encoding does not support rotation -- `uxtb r0,r1,ror ?#8'
 [^:]*:45: *Info: macro .*
 [^:]*:11: Error: lo register required -- `uxth r8,r0'
 [^:]*:21: *Info: macro .*
@@ -81,7 +81,7 @@
 [^:]*:12: Error: lo register required -- `uxth r0,r8'
 [^:]*:21: *Info: macro .*
 [^:]*:46: *Info: macro .*
-[^:]*:22: Error: Thumb encoding does not support rotation -- `uxth r0,r1,ror#8'
+[^:]*:22: Error: Thumb encoding does not support rotation -- `uxth r0,r1,ror ?#8'
 [^:]*:46: *Info: macro .*
 [^:]*:25: Error: dest must overlap one source register -- `adc r1,r2,r3'
 [^:]*:30: *Info: macro .*
@@ -94,7 +94,7 @@
 [^:]*:48: *Info: macro .*
 [^:]*:31: Error: unshifted register required -- `adc r0,#12'
 [^:]*:48: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `adc r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `adc r0,r1,lsl ?#2'
 [^:]*:48: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `adc r0,r1,lsl r3'
 [^:]*:48: *Info: macro .*
@@ -109,7 +109,7 @@
 [^:]*:49: *Info: macro .*
 [^:]*:31: Error: unshifted register required -- `and r0,#12'
 [^:]*:49: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `and r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `and r0,r1,lsl ?#2'
 [^:]*:49: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `and r0,r1,lsl r3'
 [^:]*:49: *Info: macro .*
@@ -124,7 +124,7 @@
 [^:]*:50: *Info: macro .*
 [^:]*:31: Error: unshifted register required -- `bic r0,#12'
 [^:]*:50: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `bic r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `bic r0,r1,lsl ?#2'
 [^:]*:50: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `bic r0,r1,lsl r3'
 [^:]*:50: *Info: macro .*
@@ -139,7 +139,7 @@
 [^:]*:51: *Info: macro .*
 [^:]*:31: Error: unshifted register required -- `eor r0,#12'
 [^:]*:51: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `eor r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `eor r0,r1,lsl ?#2'
 [^:]*:51: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `eor r0,r1,lsl r3'
 [^:]*:51: *Info: macro .*
@@ -154,7 +154,7 @@
 [^:]*:52: *Info: macro .*
 [^:]*:31: Error: unshifted register required -- `orr r0,#12'
 [^:]*:52: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `orr r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `orr r0,r1,lsl ?#2'
 [^:]*:52: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `orr r0,r1,lsl r3'
 [^:]*:52: *Info: macro .*
@@ -169,7 +169,7 @@
 [^:]*:53: *Info: macro .*
 [^:]*:31: Error: unshifted register required -- `sbc r0,#12'
 [^:]*:53: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `sbc r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `sbc r0,r1,lsl ?#2'
 [^:]*:53: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `sbc r0,r1,lsl r3'
 [^:]*:53: *Info: macro .*
@@ -220,7 +220,7 @@
 [^:]*:60: *Info: macro .*
 [^:]*:65: *Info: macro .*
 [^:]*:66: Error: ror #imm not supported -- `ror r0,r1,#12'
-[^:]*:69: Error: unshifted register required -- `add r0,r1,lsl#2'
+[^:]*:69: Error: unshifted register required -- `add r0,r1,lsl ?#2'
 [^:]*:70: Error: unshifted register required -- `add r0,r1,lsl r3'
 [^:]*:71: Error: lo register required -- `add r8,r0,#1'
 [^:]*:72: Error: lo register required -- `add r0,r8,#1'
@@ -236,7 +236,7 @@
 [^:]*:27: Error: lo register required -- `sub r0,r8'
 [^:]*:30: *Info: macro .*
 [^:]*:80: *Info: macro .*
-[^:]*:32: Error: unshifted register required -- `sub r0,r1,lsl#2'
+[^:]*:32: Error: unshifted register required -- `sub r0,r1,lsl ?#2'
 [^:]*:80: *Info: macro .*
 [^:]*:33: Error: unshifted register required -- `sub r0,r1,lsl r3'
 [^:]*:80: *Info: macro .*
@@ -246,10 +246,10 @@
 [^:]*:84: Error: lo register required -- `sub r8,r1,r2'
 [^:]*:85: Error: lo register required -- `sub r1,r8,r2'
 [^:]*:86: Error: lo register required -- `sub r1,r2,r8'
-[^:]*:88: Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `cmp r0,r1,lsl#2'
+[^:]*:88: Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `cmp r0,r1,lsl ?#2'
 [^:]*:89: Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `cmp r0,r1,lsl r3'
 [^:]*:90: Error: only lo regs allowed with immediate -- `cmp r8,#255'
-[^:]*:92: Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `mov r0,r1,lsl#2'
+[^:]*:92: Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `mov r0,r1,lsl ?#2'
 [^:]*:93: Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `mov r0,r1,lsl r3'
 [^:]*:94: Error: only lo regs allowed with immediate -- `mov r8,#255'
 [^:]*:98: Error: lo register required -- `ldr r8,\[r0\]'
@@ -364,8 +364,8 @@
 [^:]*:113: *Info: macro .*
 [^:]*:104: Error: Thumb does not support this addressing mode -- `strh r0,\[r1\],r2'
 [^:]*:113: *Info: macro .*
-[^:]*:115: Error: Thumb does not support this addressing mode -- `ldr r0,\[r1,r2,lsl#1\]'
-[^:]*:116: Error: Thumb does not support this addressing mode -- `str r0,\[r1,r2,lsl#1\]'
+[^:]*:115: Error: Thumb does not support this addressing mode -- `ldr r0,\[r1,r2,lsl ?#1\]'
+[^:]*:116: Error: Thumb does not support this addressing mode -- `str r0,\[r1,r2,lsl ?#1\]'
 [^:]*:119: Error: lo register required -- `ldmia r8!,{r1,r2}'
 [^:]*:120: Error: lo register required -- `ldmia r7!,{r8}'
 [^:]*:121: Warning: this instruction will write back the base register
--- a/gas/testsuite/gas/arm/thumb2_bad_reg.l
+++ b/gas/testsuite/gas/arm/thumb2_bad_reg.l
@@ -514,7 +514,7 @@
 [^:]*:[0-9]+: Error: r15 not allowed here -- `ssat r15,#1,r0'
 [^:]*:[0-9]+: Error: r13 not allowed here -- `ssat r0,#1,r13'
 [^:]*:[0-9]+: Error: r15 not allowed here -- `ssat r0,#1,r15'
-[^:]*:[0-9]+: Error: shift expression is too large -- `ssat r1,#1,r3,asr#32'
+[^:]*:[0-9]+: Error: shift expression is too large -- `ssat r1,#1,r3,asr ?#32'
 [^:]*:[0-9]+: Error: r13 not allowed here -- `ssat16 r13,#1,r0'
 [^:]*:[0-9]+: Error: r15 not allowed here -- `ssat16 r15,#1,r0'
 [^:]*:[0-9]+: Error: r13 not allowed here -- `ssat16 r0,#1,r13'
@@ -742,7 +742,7 @@
 [^:]*:[0-9]+: Error: r15 not allowed here -- `usat r15,#1,r0'
 [^:]*:[0-9]+: Error: r13 not allowed here -- `usat r0,#1,r13'
 [^:]*:[0-9]+: Error: r15 not allowed here -- `usat r0,#1,r15'
-[^:]*:[0-9]+: Error: shift expression is too large -- `usat r1,#1,r3,asr#32'
+[^:]*:[0-9]+: Error: shift expression is too large -- `usat r1,#1,r3,asr ?#32'
 [^:]*:[0-9]+: Error: r13 not allowed here -- `usat16 r13,#1,r0'
 [^:]*:[0-9]+: Error: r15 not allowed here -- `usat16 r15,#1,r0'
 [^:]*:[0-9]+: Error: r13 not allowed here -- `usat16 r0,#1,r13'


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 14/17] aarch64: relax gas testsuite whitespace expectations
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (12 preceding siblings ...)
  2024-07-12 13:07 ` [PATCH v2 13/17] Arm: relax gas testsuite whitespace expectations Jan Beulich
@ 2024-07-12 13:10 ` Jan Beulich
  2024-07-12 13:11 ` [PATCH v2 15/17] MIPS: " Jan Beulich
                   ` (5 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:10 UTC (permalink / raw)
  To: Binutils; +Cc: Richard Earnshaw, Marcus Shawcroft

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
---
This is adding just the blanks that are going to be needed; imo it would
generally be better if test case expectations were, from the very
beginning, written to focus on what is being tested, rather than taking
verbatim copies of the respective tool's output.

(actual patch attached in compressed form, due to size)

[-- Attachment #2: binutils-master-gas-testsuite-relax-Arm64.gz --]
[-- Type: application/x-gzip, Size: 117830 bytes --]

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (13 preceding siblings ...)
  2024-07-12 13:10 ` [PATCH v2 14/17] aarch64: " Jan Beulich
@ 2024-07-12 13:11 ` Jan Beulich
  2024-07-15 12:12   ` Maciej W. Rozycki
  2024-07-12 13:12 ` [PATCH v2 16/17] Sparc: " Jan Beulich
                   ` (4 subsequent siblings)
  19 siblings, 1 reply; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:11 UTC (permalink / raw)
  To: Binutils; +Cc: Maciej W. Rozycki, Chenghua Xu

In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
---
This is adding just the blanks that are going to be needed; imo it would
generally be better if test case expectations were, from the very
beginning, written to focus on what is being tested, rather than taking
verbatim copies of the respective tool's output.
---
v2: New.

--- a/gas/testsuite/gas/mips/micromips.l
+++ b/gas/testsuite/gas/mips/micromips.l
@@ -64,18 +64,18 @@
 .*:3133: Error: opcode not supported in the `insn32' mode `addiur2 \$17,\$17,16'
 .*:3134: Error: opcode not supported in the `insn32' mode `addiur2 \$17,\$17,20'
 .*:3135: Error: opcode not supported in the `insn32' mode `addiur2 \$17,\$17,24'
-.*:3137: Error: opcode not supported in the `insn32' mode `addiusp 2<<2'
-.*:3138: Error: opcode not supported in the `insn32' mode `addiusp 3<<2'
-.*:3139: Error: opcode not supported in the `insn32' mode `addiusp 254<<2'
-.*:3140: Error: opcode not supported in the `insn32' mode `addiusp 255<<2'
-.*:3141: Error: opcode not supported in the `insn32' mode `addiusp 256<<2'
-.*:3142: Error: opcode not supported in the `insn32' mode `addiusp 257<<2'
-.*:3143: Error: opcode not supported in the `insn32' mode `addiusp -3<<2'
-.*:3144: Error: opcode not supported in the `insn32' mode `addiusp -4<<2'
-.*:3145: Error: opcode not supported in the `insn32' mode `addiusp -255<<2'
-.*:3146: Error: opcode not supported in the `insn32' mode `addiusp -256<<2'
-.*:3147: Error: opcode not supported in the `insn32' mode `addiusp -257<<2'
-.*:3148: Error: opcode not supported in the `insn32' mode `addiusp -258<<2'
+.*:3137: Error: opcode not supported in the `insn32' mode `addiusp 2 ?<< ?2'
+.*:3138: Error: opcode not supported in the `insn32' mode `addiusp 3 ?<< ?2'
+.*:3139: Error: opcode not supported in the `insn32' mode `addiusp 254 ?<< ?2'
+.*:3140: Error: opcode not supported in the `insn32' mode `addiusp 255 ?<< ?2'
+.*:3141: Error: opcode not supported in the `insn32' mode `addiusp 256 ?<< ?2'
+.*:3142: Error: opcode not supported in the `insn32' mode `addiusp 257 ?<< ?2'
+.*:3143: Error: opcode not supported in the `insn32' mode `addiusp -3 ?<< ?2'
+.*:3144: Error: opcode not supported in the `insn32' mode `addiusp -4 ?<< ?2'
+.*:3145: Error: opcode not supported in the `insn32' mode `addiusp -255 ?<< ?2'
+.*:3146: Error: opcode not supported in the `insn32' mode `addiusp -256 ?<< ?2'
+.*:3147: Error: opcode not supported in the `insn32' mode `addiusp -257 ?<< ?2'
+.*:3148: Error: opcode not supported in the `insn32' mode `addiusp -258 ?<< ?2'
 .*:3150: Error: opcode not supported in the `insn32' mode `addius5 \$0,0'
 .*:3151: Error: opcode not supported in the `insn32' mode `addius5 \$2,0'
 .*:3152: Error: opcode not supported in the `insn32' mode `addius5 \$3,0'
--- a/gas/testsuite/gas/mips/mips16-32@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16-32@mips16-insn-e.l
@@ -117,12 +117,12 @@
 .*:171: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.e \$29,0'
 .*:172: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.e \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: mips1 \(mips1\) `ld\.e \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: mips1 \(mips1\) `ld\.e \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: mips1 \(mips1\) `ld\.e \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: mips1 \(mips1\) `daddiu\.e \$16,0'
 .*:177: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.e \$16,0'
 .*:179: Error: opcode not supported on this processor: mips1 \(mips1\) `daddiu\.e \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.e \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: mips1 \(mips1\) `dla\.e \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: mips1 \(mips1\) `dla\.e \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: mips1 \(mips1\) `daddiu\.e \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.e \$16,\$sp,0'
 .*:10: Warning: extended operand requested but not required
--- a/gas/testsuite/gas/mips/mips16-32@mips16-insn-t.l
+++ b/gas/testsuite/gas/mips/mips16-32@mips16-insn-t.l
@@ -44,11 +44,11 @@
 .*:171: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.t \$29,0'
 .*:172: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.t \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: mips1 \(mips1\) `ld\.t \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: mips1 \(mips1\) `ld\.t \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: mips1 \(mips1\) `ld\.t \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: mips1 \(mips1\) `daddiu\.t \$16,0'
 .*:177: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.t \$16,0'
 .*:179: Error: opcode not supported on this processor: mips1 \(mips1\) `daddiu\.t \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.t \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: mips1 \(mips1\) `dla\.t \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: mips1 \(mips1\) `dla\.t \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: mips1 \(mips1\) `daddiu\.t \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: mips1 \(mips1\) `daddu\.t \$16,\$sp,0'
--- a/gas/testsuite/gas/mips/mips16e-32@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16e-32@mips16-insn-e.l
@@ -115,12 +115,12 @@
 .*:171: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.e \$29,0'
 .*:172: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.e \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: mips32 \(mips32\) `ld\.e \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: mips32 \(mips32\) `ld\.e \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: mips32 \(mips32\) `ld\.e \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: mips32 \(mips32\) `daddiu\.e \$16,0'
 .*:177: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.e \$16,0'
 .*:179: Error: opcode not supported on this processor: mips32 \(mips32\) `daddiu\.e \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.e \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: mips32 \(mips32\) `dla\.e \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: mips32 \(mips32\) `dla\.e \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: mips32 \(mips32\) `daddiu\.e \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.e \$16,\$sp,0'
 .*:10: Warning: extended operand requested but not required
--- a/gas/testsuite/gas/mips/mips16e-32@mips16-insn-t.l
+++ b/gas/testsuite/gas/mips/mips16e-32@mips16-insn-t.l
@@ -33,11 +33,11 @@
 .*:171: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.t \$29,0'
 .*:172: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.t \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: mips32 \(mips32\) `ld\.t \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: mips32 \(mips32\) `ld\.t \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: mips32 \(mips32\) `ld\.t \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: mips32 \(mips32\) `daddiu\.t \$16,0'
 .*:177: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.t \$16,0'
 .*:179: Error: opcode not supported on this processor: mips32 \(mips32\) `daddiu\.t \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.t \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: mips32 \(mips32\) `dla\.t \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: mips32 \(mips32\) `dla\.t \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: mips32 \(mips32\) `daddiu\.t \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: mips32 \(mips32\) `daddu\.t \$16,\$sp,0'
--- a/gas/testsuite/gas/mips/mips16e2-32@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16e2-32@mips16-insn-e.l
@@ -115,12 +115,12 @@
 .*:171: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.e \$29,0'
 .*:172: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.e \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `ld\.e \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `ld\.e \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `ld\.e \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddiu\.e \$16,0'
 .*:177: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.e \$16,0'
 .*:179: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddiu\.e \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.e \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `dla\.e \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `dla\.e \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddiu\.e \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.e \$16,\$sp,0'
 .*:10: Warning: extended operand requested but not required
--- a/gas/testsuite/gas/mips/mips16e2-32@mips16-insn-t.l
+++ b/gas/testsuite/gas/mips/mips16e2-32@mips16-insn-t.l
@@ -33,11 +33,11 @@
 .*:171: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.t \$29,0'
 .*:172: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.t \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `ld\.t \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `ld\.t \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `ld\.t \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddiu\.t \$16,0'
 .*:177: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.t \$16,0'
 .*:179: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddiu\.t \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.t \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `dla\.t \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `dla\.t \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddiu\.t \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: mips32r2 \(mips32r2\) `daddu\.t \$16,\$sp,0'
--- a/gas/testsuite/gas/mips/mips16e2-interaptiv-mr2@mips16-insn-e.l
+++ b/gas/testsuite/gas/mips/mips16e2-interaptiv-mr2@mips16-insn-e.l
@@ -115,12 +115,12 @@
 .*:171: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.e \$29,0'
 .*:172: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.e \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `ld\.e \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `ld\.e \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `ld\.e \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddiu\.e \$16,0'
 .*:177: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.e \$16,0'
 .*:179: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddiu\.e \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.e \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `dla\.e \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `dla\.e \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddiu\.e \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.e \$16,\$sp,0'
 .*:10: Warning: extended operand requested but not required
--- a/gas/testsuite/gas/mips/mips16e2-interaptiv-mr2@mips16-insn-t.l
+++ b/gas/testsuite/gas/mips/mips16e2-interaptiv-mr2@mips16-insn-t.l
@@ -33,11 +33,11 @@
 .*:171: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.t \$29,0'
 .*:172: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.t \$29,\$29,0'
 .*:174: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `ld\.t \$16,0\(\$pc\)'
-.*:175: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `ld\.t \$16,\.-3'
+.*:175: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `ld\.t \$16,\. ?- ?3'
 .*:176: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddiu\.t \$16,0'
 .*:177: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.t \$16,0'
 .*:179: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddiu\.t \$16,\$pc,0'
 .*:180: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.t \$16,\$pc,0'
-.*:181: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `dla\.t \$16,\.-1'
+.*:181: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `dla\.t \$16,\. ?- ?1'
 .*:182: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddiu\.t \$16,\$sp,0'
 .*:183: Error: opcode not supported on this processor: interaptiv-mr2 \(mips32r3\) `daddu\.t \$16,\$sp,0'
--- a/gas/testsuite/gas/mips/mips16e2@lui-2.l
+++ b/gas/testsuite/gas/mips/mips16e2@lui-2.l
@@ -1,5 +1,5 @@
 .*: Assembler messages:
-.*:7: Error: operand 2 must be constant `lui \$2,bar-foo'
-.*:8: Error: operand 2 must be constant `lui \$2,baz-bar'
-.*:9: Error: operand 2 must be constant `lui \$2,foo-baz'
-.*:10: Error: operand 2 must be constant `lui \$2,bar/baz'
+.*:7: Error: operand 2 must be constant `lui \$2,bar ?- ?foo'
+.*:8: Error: operand 2 must be constant `lui \$2,baz ?- ?bar'
+.*:9: Error: operand 2 must be constant `lui \$2,foo ?- ?baz'
+.*:10: Error: operand 2 must be constant `lui \$2,bar ?/ ?baz'


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 16/17] Sparc: relax gas testsuite whitespace expectations
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (14 preceding siblings ...)
  2024-07-12 13:11 ` [PATCH v2 15/17] MIPS: " Jan Beulich
@ 2024-07-12 13:12 ` Jan Beulich
  2024-07-15 14:17   ` Jose E. Marchesi
  2024-07-12 13:18 ` [PATCH v2 17/17] gas: have scrubber retain more whitespace Jan Beulich
                   ` (3 subsequent siblings)
  19 siblings, 1 reply; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:12 UTC (permalink / raw)
  To: Binutils; +Cc: David S. Miller, Jose Marchesi

In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
---
This is adding just the blank that is going to be needed; imo it would
generally be better if test case expectations were, from the very
beginning, written to focus on what is being tested, rather than taking
verbatim copies of the respective tool's output.
---
v2: New.

--- a/gas/testsuite/gas/sparc/asi-arch-error.l
+++ b/gas/testsuite/gas/sparc/asi-arch-error.l
@@ -1,3 +1,3 @@
 .*asi-arch-error.s: Assembler messages:
-.*asi-arch-error.s:3: Error: Architecture mismatch on "ldda \[%g0]#ASI_FL16_P,%f0".
+.*asi-arch-error.s:3: Error: Architecture mismatch on "ldda \[%g0] ?#ASI_FL16_P,%f0".
 .*asi-arch-error.s:3: \(Requires v9b\|v9c\|v9d\|v9e\|v9v\|v9m.*; requested architecture is v9.\)


^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2 17/17] gas: have scrubber retain more whitespace
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (15 preceding siblings ...)
  2024-07-12 13:12 ` [PATCH v2 16/17] Sparc: " Jan Beulich
@ 2024-07-12 13:18 ` Jan Beulich
  2024-07-14 14:29 ` [PATCH v2 00/17] gas: scrubber adjustments Alan Modra
                   ` (2 subsequent siblings)
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-12 13:18 UTC (permalink / raw)
  To: Binutils
  Cc: Richard Earnshaw, Marcus Shawcroft, M R Swami Reddy, Lifang Xia,
	Yunhai Shang, David S. Miller, Jose Marchesi, Kuan-Lin Chen,
	Wei-Cheng Wang, Doug Evans, Frank Ch. Eigler, H.J. Lu

According to the description of the state machine, the expectation
appears to be that (leaving aside labels) any insn mnemonic or
directive would be followed by a comma separated list of operands. That
may have been true very long ago, but the latest with the advent of more
elaborate macros this isn't rhe case anymore. Neither macro parameters
in macro definitions nor macro arguments in macro invocations are
required to be separated by commas. Hence whitespace serves a crucial
role there. Plus even without "real" macros issues exist, in e.g.

	.irp n, ...
	insn\n\(suffix)	operand1, operand2
	.endr

Whitespace following the closing parenthesis would have been removed
(ahead of even processing the .irp), as the "opcode" was deemed to have
ended earlier already.

Therefore, squash the distinction between "opcode" and operands, i.e.
fold state 10 back into state 3. Also drop most of the distinction
between "symbol chars" and "relatively normal" ones. Not entirely
unexpectedly this results in the need to skip whitespace in a few more
places in arch-specific code (and quite likely more changes are needed
for insn forms not covered by the testsuite).

As a result the D10V special case is no longer necessary.

In config/tc-sparc.c also move a comment to be next to the code being
commented.

In opcodes/cgen-asm.in some further cleanup is done, following the local
var adjustments.
---
WIP: NEWS entry (perhaps also to warn people of posible perceived
     regressions, along the lines of what "Arm: correct macro use in gas
     testsuite" addresses)

Diffs of updates to generated files (CGEN) omitted here.

In config/tc-sparc.c the second of the "else if" touched looks
suspicious: Without looking at s1[-2], how can s1[-3] be reliably of the
expected meaning? Is there perhaps ISDIGIT(s1[-2]) missing?
---
v2: Further target-specific adjustments. However, drop the earlier x86
    adjustment as no longer necessary.

--- a/gas/app.c
+++ b/gas/app.c
@@ -471,16 +471,18 @@ do_scrub_chars (size_t (*get) (char *, s
 
   /*State 0: beginning of normal line
 	  1: After first whitespace on line (flush more white)
-	  2: After first non-white (opcode) on line (keep 1white)
-	  3: after second white on line (into operands) (flush white)
+	  2: After first non-white (opcode or maybe label when they're followed
+	     by colons) on line (keep 1white)
+	  3: after subsequent white on line (typically into operands)
+	     (flush more white)
 	  4: after putting out a .linefile, put out digits
 	  5: parsing a string, then go to old-state
 	  6: putting out \ escape in a "d string.
 	  7: no longer used
 	  8: no longer used
-	  9: After seeing symbol char in state 3 (keep 1white after symchar)
-	 10: After seeing whitespace in state 9 (keep white before symchar)
-	 11: After seeing a symbol character in state 0 (eg a label definition)
+	  9: After seeing non-white in state 3 (keep 1white)
+	 10: no longer used
+	 11: After seeing a non-white character in state 0 (eg a label definition)
 	 -1: output string in out_string and go to the state in old_state
 	 12: no longer used
 #ifdef DOUBLEBAR_PARALLEL
@@ -941,7 +943,11 @@ do_scrub_chars (size_t (*get) (char *, s
 	          && (state < 1 || strchr (tc_comment_chars, ch)))
 	      || IS_NEWLINE (ch)
 	      || IS_LINE_SEPARATOR (ch)
-	      || IS_PARALLEL_SEPARATOR (ch))
+	      || IS_PARALLEL_SEPARATOR (ch)
+	      /* See comma related comment near the bottom of the function.
+		 Reasoning equally applies to whitespace preceding a comma in
+		 most cases.  */
+	      || (ch == ',' && state > 2 && state != 11))
 	    {
 	      if (scrub_m68k_mri)
 		{
@@ -984,6 +990,7 @@ do_scrub_chars (size_t (*get) (char *, s
 		 character at the beginning of a line.  */
 	      goto recycle;
 	    case 2:
+	    case 9:
 	      state = 3;
 	      if (to + 1 < toend)
 		{
@@ -1007,20 +1014,6 @@ do_scrub_chars (size_t (*get) (char *, s
 		  break;
 		}
 	      goto recycle;	/* Sp in operands */
-	    case 9:
-	    case 10:
-#ifndef TC_KEEP_OPERAND_SPACES
-	      if (scrub_m68k_mri)
-#endif
-		{
-		  /* In MRI mode, we keep these spaces.  */
-		  state = 3;
-		  UNGET (ch);
-		  PUT (' ');
-		  break;
-		}
-	      state = 10;	/* Sp after symbol char */
-	      goto recycle;
 	    case 11:
 	      if (LABELS_WITHOUT_COLONS || flag_m68k_mri)
 		state = 1;
@@ -1091,27 +1084,17 @@ do_scrub_chars (size_t (*get) (char *, s
 	    {
 	      if (ch2 != EOF)
 		UNGET (ch2);
-	      if (state == 9 || state == 10)
-		state = 3;
+	      if (state == 1)
+		state = 2;
+	      else if (state == 3)
+		state = 9;
 	      PUT (ch);
 	    }
 	  break;
 
 	case LEX_IS_STRINGQUOTE:
 	  quotechar = ch;
-	  if (state == 10)
-	    {
-	      /* Preserve the whitespace in foo "bar".  */
-	      UNGET (ch);
-	      state = 3;
-	      PUT (' ');
-
-	      /* PUT didn't jump out.  We could just break, but we
-		 know what will happen, so optimize a bit.  */
-	      ch = GET ();
-	      old_state = 9;
-	    }
-	  else if (state == 3)
+	  if (state == 3)
 	    old_state = 9;
 	  else
 	    old_state = state;
@@ -1130,14 +1113,6 @@ do_scrub_chars (size_t (*get) (char *, s
 	      UNGET (c);
 	    }
 #endif
-	  if (state == 10)
-	    {
-	      /* Preserve the whitespace in foo 'b'.  */
-	      UNGET (ch);
-	      state = 3;
-	      PUT (' ');
-	      break;
-	    }
 	  ch = GET ();
 	  if (ch == EOF)
 	    {
@@ -1172,10 +1147,7 @@ do_scrub_chars (size_t (*get) (char *, s
 	      PUT (out_buf[0]);
 	      break;
 	    }
-	  if (state == 9)
-	    old_state = 3;
-	  else
-	    old_state = state;
+	  old_state = state;
 	  state = -1;
 	  out_string = out_buf;
 	  PUT (*out_string++);
@@ -1185,10 +1157,10 @@ do_scrub_chars (size_t (*get) (char *, s
 #ifdef KEEP_WHITE_AROUND_COLON
 	  state = 9;
 #else
-	  if (state == 9 || state == 10)
-	    state = 3;
-	  else if (state != 3)
+	  if (state == 2 || state == 11)
 	    state = 1;
+	  else
+	    state = 9;
 #endif
 	  PUT (ch);
 	  break;
@@ -1313,20 +1285,6 @@ do_scrub_chars (size_t (*get) (char *, s
 	      break;
 	    }
 
-#ifdef TC_D10V
-	  /* All insns end in a char for which LEX_IS_SYMBOL_COMPONENT is true.
-	     Trap is the only short insn that has a first operand that is
-	     neither register nor label.
-	     We must prevent exef0f ||trap #1 to degenerate to exef0f ||trap#1 .
-	     We can't make '#' LEX_IS_SYMBOL_COMPONENT because it is
-	     already LEX_IS_LINE_COMMENT_START.  However, it is the
-	     only character in line_comment_chars for d10v, hence we
-	     can recognize it as such.  */
-	  /* An alternative approach would be to reset the state to 1 when
-	     we see '||', '<'- or '->', but that seems to be overkill.  */
-	  if (state == 10)
-	    PUT (' ');
-#endif
 	  /* We have a line comment character which is not at the
 	     start of a line.  If this is also a normal comment
 	     character, fall through.  Otherwise treat it as a default
@@ -1390,17 +1348,6 @@ do_scrub_chars (size_t (*get) (char *, s
 	  /* Fall through.  */
 
 	case LEX_IS_SYMBOL_COMPONENT:
-	  if (state == 10)
-	    {
-	      /* This is a symbol character following another symbol
-		 character, with whitespace in between.  We skipped
-		 the whitespace earlier, so output it now.  */
-	      UNGET (ch);
-	      state = 3;
-	      PUT (' ');
-	      break;
-	    }
-
 #ifdef TC_Z80
 	  /* "af'" is a symbol containing '\''.  */
 	  if (state == 3 && (ch == 'a' || ch == 'A'))
@@ -1426,7 +1373,16 @@ do_scrub_chars (size_t (*get) (char *, s
 		}
 	    }
 #endif
-	  if (state == 3)
+
+	  /* Fall through.  */
+	default:
+	de_fault:
+	  /* Some relatively `normal' character.  */
+	  if (state == 0)
+	    state = 11;	/* Now seeing label definition.  */
+	  else if (state == 1)
+	    state = 2;	/* Ditto.  */
+	  else if (state == 3)
 	    state = 9;
 
 	  /* This is a common case.  Quickly copy CH and all the
@@ -1436,6 +1392,10 @@ do_scrub_chars (size_t (*get) (char *, s
 #if defined TC_ARM && defined OBJ_ELF
 	      && symver_state == NULL
 #endif
+#ifdef TC_Z80
+	      /* See comma related comment below.  */
+	      && ch != ','
+#endif
 	      )
 	    {
 	      char *s;
@@ -1450,6 +1410,12 @@ do_scrub_chars (size_t (*get) (char *, s
 		  if (type != 0
 		      && type != LEX_IS_SYMBOL_COMPONENT)
 		    break;
+#ifdef TC_Z80
+		  /* Need to split at commas, to be able to enter state 16
+		     when needed.  */
+		  if (ch2 == ',')
+		    break;
+#endif
 		}
 
 	      if (s > from)
@@ -1474,52 +1440,15 @@ do_scrub_chars (size_t (*get) (char *, s
 		}
 	    }
 
-	  /* Fall through.  */
-	default:
-	de_fault:
-	  /* Some relatively `normal' character.  */
-	  if (state == 0)
-	    {
-	      state = 11;	/* Now seeing label definition.  */
-	    }
-	  else if (state == 1)
-	    {
-	      state = 2;	/* Ditto.  */
-	    }
-	  else if (state == 9)
-	    {
-	      if (!IS_SYMBOL_COMPONENT (ch))
-		state = 3;
-	    }
-	  else if (state == 10)
-	    {
-	      if (ch == '\\')
-		{
-		  /* Special handling for backslash: a backslash may
-		     be the beginning of a formal parameter (of a
-		     macro) following another symbol character, with
-		     whitespace in between.  If that is the case, we
-		     output a space before the parameter.  Strictly
-		     speaking, correct handling depends upon what the
-		     macro parameter expands into; if the parameter
-		     expands into something which does not start with
-		     an operand character, then we don't want to keep
-		     the space.  We don't have enough information to
-		     make the right choice, so here we are making the
-		     choice which is more likely to be correct.  */
-		  if (to + 1 >= toend)
-		    {
-		      /* If we're near the end of the buffer, save the
-		         character for the next time round.  Otherwise
-		         we'll lose our state.  */
-		      UNGET (ch);
-		      goto tofull;
-		    }
-		  *to++ = ' ';
-		}
+	  /* As a special case, to limit the delta to previous behavior, e.g.
+	     also affecting listings, go straight to state 3 when seeing a
+	     comma. Commas are special: While they can be used to separate
+	     macro parameters or arguments, they cannot (on their own, i.e.
+	     without quoting) be arguments (or parameter default values).
+	     Hence successive whitespace is not meaningful there.  */
+	  if (ch == ',' && state == 9)
+	    state = 3;
 
-	      state = 3;
-	    }
 	  PUT (ch);
 	  break;
 	}
--- a/gas/config/tc-aarch64.c
+++ b/gas/config/tc-aarch64.c
@@ -641,6 +641,7 @@ const char FLT_CHARS[] = "rRsSfFdDxXeEpP
 static inline bool
 skip_past_char (char **str, char c)
 {
+  skip_whitespace (*str);
   if (**str == c)
     {
       (*str)++;
@@ -891,6 +892,7 @@ parse_reg (char **ccp)
   start++;
 #endif
 
+  skip_whitespace (start);
   p = start;
   if (!ISALPHA (*p) || !is_name_beginner (*p))
     return NULL;
@@ -1196,13 +1198,17 @@ parse_typed_reg (char **ccp, aarch64_reg
 		 struct vector_type_el *typeinfo, unsigned int flags)
 {
   char *str = *ccp;
-  bool is_alpha = ISALPHA (*str);
-  const reg_entry *reg = parse_reg (&str);
+  bool is_alpha;
+  const reg_entry *reg;
   struct vector_type_el atype;
   struct vector_type_el parsetype;
   bool is_typed_vecreg = false;
   unsigned int err_flags = (flags & PTR_IN_REGLIST) ? SEF_IN_REGLIST : 0;
 
+  skip_whitespace (str);
+  is_alpha = ISALPHA (*str);
+  reg = parse_reg (&str);
+
   atype.defined = 0;
   atype.type = NT_invtype;
   atype.width = -1;
@@ -1420,10 +1426,7 @@ parse_vector_reg_list (char **ccp, aarch
   do
     {
       if (in_range)
-	{
-	  str++;		/* skip over '-' */
-	  val_range = val;
-	}
+	val_range = val;
 
       const reg_entry *reg;
       if (has_qualifier)
@@ -1485,7 +1488,8 @@ parse_vector_reg_list (char **ccp, aarch
       in_range = 0;
       ptr_flags |= PTR_GOOD_MATCH;
     }
-  while (skip_past_comma (&str) || (in_range = 1, *str == '-'));
+  while (skip_past_comma (&str)
+	 || (in_range = 1, skip_past_char (&str, '-')));
 
   skip_whitespace (str);
   if (*str != '}')
@@ -8265,6 +8269,7 @@ parse_operands (char *str, const aarch64
     }
 
   /* Check if we have parsed all the operands.  */
+  skip_whitespace (str);
   if (*str != '\0' && ! error_p ())
     {
       /* Set I to the index of the last present operand; this is
--- a/gas/config/tc-arm.c
+++ b/gas/config/tc-arm.c
@@ -1148,6 +1148,8 @@ my_get_expression (expressionS * ep, cha
     prefix_mode = (prefix_mode == GE_OPT_PREFIX_BIG) ? prefix_mode
 		  : GE_OPT_PREFIX;
 
+  skip_whitespace (*str);
+
   switch (prefix_mode)
     {
     case GE_NO_PREFIX: break;
--- a/gas/config/tc-crx.c
+++ b/gas/config/tc-crx.c
@@ -1723,9 +1723,13 @@ preprocess_reglist (char *param, int *al
 
   while (*paramP != '}')
     {
-      regP = paramP;
       memset (&reg_name, '\0', sizeof (reg_name));
 
+      while (ISSPACE (*paramP))
+	paramP++;
+
+      regP = paramP;
+
       while (ISALNUM (*paramP))
 	paramP++;
 
--- a/gas/config/tc-csky.c
+++ b/gas/config/tc-csky.c
@@ -2409,10 +2409,18 @@ parse_rt (char *s,
     /* Indicate nothing there.  */
     ep->X_op = O_absent;
 
+  /* Skip whitespace.  */
+  while (ISSPACE (*s))
+    ++s;
+
   if (*s == '[')
     {
       s = parse_exp (s + 1, &e);
 
+      /* Skip whitespace.  */
+      while (ISSPACE (*s))
+	++s;
+
       if (*s == ']')
 	s++;
       else
@@ -2935,6 +2943,11 @@ is_reg_lshift_illegal (char **oper, int
     }
 
   *oper += len;
+
+  /* Skip whitespace.  */
+  while (ISSPACE (**oper))
+    ++*oper;
+
   if ((*oper)[0] != '<' || (*oper)[1] != '<')
     {
       SET_ERROR_STRING (ERROR_UNDEFINE,
@@ -3461,6 +3474,9 @@ get_operand_value (struct csky_opcode_in
 	  return false;
 	}
 
+      while (ISSPACE (**oper))
+	++*oper;
+
       if (!get_operand_value (op, oper, &soprnd->subs[0]))
 	{
 	  *s = rc;
@@ -3481,7 +3497,7 @@ get_operand_value (struct csky_opcode_in
 	}
 
       *s = rc;
-      *oper += 1;
+      *oper = s + 1;
       return true;
     }
 
@@ -4277,11 +4293,16 @@ get_operand_value (struct csky_opcode_in
     case OPRND_TYPE_VREG_WITH_INDEX:
       if (parse_type_freg (oper, 0))
 	{
+	  /* Skip whitespace.  */
+	  while (ISSPACE (**oper))
+	    ++*oper;
 	  if (**oper == '[')
 	    {
 	      (*oper)++;
 	      if (is_imm_within_range (oper, 0, 0xf))
 		{
+		  while (ISSPACE (**oper))
+		    ++*oper;
 		  if (**oper == ']')
 		    {
 		      unsigned int idx = --csky_insn.idx;
--- a/gas/config/tc-pru.c
+++ b/gas/config/tc-pru.c
@@ -1399,7 +1399,6 @@ pru_parse_args (pru_insn_infoS *insn ATT
 		  const char *parsestr, char **parsed_args)
 {
   char *p;
-  char *end = NULL;
   int i;
   p = argstr;
   i = 0;
@@ -1426,14 +1425,7 @@ pru_parse_args (pru_insn_infoS *insn ATT
       else
 	{
 	  /* Check that the argument string has no trailing arguments.  */
-	  /* If we've got a %pmem relocation, we've zapped the parens with
-	     spaces.  */
-	  if (strprefix (p, "%pmem") || strprefix (p, "%label"))
-	    end = strpbrk (p, ",");
-	  else
-	    end = strpbrk (p, " ,");
-
-	  if (end != NULL)
+	  if (strpbrk (p, ",") != NULL)
 	    as_bad (_("too many arguments"));
 	}
 
--- a/gas/config/tc-sparc.c
+++ b/gas/config/tc-sparc.c
@@ -1778,6 +1778,9 @@ sparc_ip (char *str, const struct sparc_
          operands match.  */
       for (args = insn->args;; ++args)
 	{
+	  if (*s == ' ' && *args != ' ')
+	    ++s;
+
 	  switch (*args)
 	    {
 	    case 'K':
@@ -2717,11 +2720,6 @@ sparc_ip (char *str, const struct sparc_
 		   'symbols' in the input string.  Try not to create U
 		   symbols for registers, etc.  */
 
-		/* This stuff checks to see if the expression ends in
-		   +%reg.  If it does, it removes the register from
-		   the expression, and re-sets 's' to point to the
-		   right place.  */
-
 		if (op_arg)
 		  {
 		    int npar = 0;
@@ -2751,6 +2749,8 @@ sparc_ip (char *str, const struct sparc_
 			return special_case;
 		      }
 		    s = s1 + 1;
+		    if (*s == ' ')
+		      s++;
 		    if (*s == ',' || *s == ']' || !*s)
 		      continue;
 		    if (*s != '+' && *s != '-')
@@ -2764,17 +2764,45 @@ sparc_ip (char *str, const struct sparc_
 		    memset (&the_insn.exp, 0, sizeof (the_insn.exp));
 		  }
 
+		/* This stuff checks to see if the expression ends in
+		   +%reg.  If it does, it removes the register from
+		   the expression, and re-sets 's' to point to the
+		   right place.  */
+
 		for (s1 = s; *s1 && *s1 != ',' && *s1 != ']'; s1++)
 		  ;
 
+		if (s1 != s && s1[-1] == ' ')
+		  --s1;
 		if (s1 != s && ISDIGIT (s1[-1]))
 		  {
 		    if (s1[-2] == '%' && s1[-3] == '+')
-		      s1 -= 3;
-		    else if (strchr ("golir0123456789", s1[-2]) && s1[-3] == '%' && s1[-4] == '+')
-		      s1 -= 4;
-		    else if (s1[-3] == 'r' && s1[-4] == '%' && s1[-5] == '+')
-		      s1 -= 5;
+		      {
+			if (s1[-3] == '+')
+			  s1 -= 3;
+			else if (s1[-3] == ' ' && s1[-4] == '+')
+			  s1 -= 4;
+			else
+			  s1 = NULL;
+		      }
+		    else if (strchr ("golir0123456789", s1[-2]) && s1[-3] == '%')
+		      {
+			if (s1[-4] == '+')
+			  s1 -= 4;
+			else if (s1[-4] == ' ' && s1[-5] == '+')
+			  s1 -= 5;
+			else
+			  s1 = NULL;
+		      }
+		    else if (s1[-3] == 'r' && s1[-4] == '%')
+		      {
+			if (s1[-5] == '+')
+			  s1 -= 5;
+			else if (s1[-5] == ' ' && s1[-6] == '+')
+			  s1 -= 6;
+			else
+			  s1 = NULL;
+		      }
 		    else
 		      s1 = NULL;
 		    if (s1)
--- a/gas/config/tc-v850.c
+++ b/gas/config/tc-v850.c
@@ -1456,6 +1456,8 @@ parse_register_list (unsigned long *insn
 	    }
 	}
 
+      skip_white_space ();
+
       if (*input_line_pointer == '}')
 	{
 	  input_line_pointer++;
@@ -1475,6 +1477,8 @@ parse_register_list (unsigned long *insn
 	  /* Skip the dash.  */
 	  ++input_line_pointer;
 
+	  skip_white_space ();
+
 	  /* Get the second register in the range.  */
 	  if (! register_name (&exp2))
 	    {
--- a/gas/testsuite/gas/all/macro.l
+++ b/gas/testsuite/gas/all/macro.l
@@ -22,4 +22,14 @@
 [ 	]*[1-9][0-9]*[ 	]+.... 0+70*[ 	]+>  .byte 7
 [ 	]*[1-9][0-9]*[ 	]+.... 0+80*[ 	]+>  .byte 8
 [ 	]*[1-9][0-9]*[ 	]+m[ 	]+""[ 	]+""[ 	]+""
+[ 	]*[1-9][0-9]*[ 	]+
+[ 	]*[1-9][0-9]*[ 	]+m[ 	]+1[ 	]+\+2
+[ 	]*[1-9][0-9]*[ 	]+.... 0+10*[ 	]+>  .byte 1
+[ 	]*[1-9][0-9]*[ 	]+.... 0+20*[ 	]+>  .byte \+2
+[ 	]*[1-9][0-9]*[ 	]+m[ 	]+\(3\)[ 	]+\+4
+[ 	]*[1-9][0-9]*[ 	]+.... 0+30*[ 	]+>  .byte \(3\)
+[ 	]*[1-9][0-9]*[ 	]+.... 0+40*[ 	]+>  .byte \+4
+[ 	]*[1-9][0-9]*[ 	]+m[ 	]+\(5\)[ 	]+\(6\)
+[ 	]*[1-9][0-9]*[ 	]+.... 0+50*[ 	]+>  .byte \(5\)
+[ 	]*[1-9][0-9]*[ 	]+.... 0+60*[ 	]+>  .byte \(6\)
 #pass
--- a/gas/testsuite/gas/all/macro.s
+++ b/gas/testsuite/gas/all/macro.s
@@ -9,8 +9,8 @@
 	m "7" "8"
 	m "" "" ""
 
-	.if 0
 	m 1 +2
 	m (3) +4
 	m (5) (6)
-	.endif
+
+	.byte -1
--- a/gas/testsuite/gas/i386/x86-64-apx-nf.s
+++ b/gas/testsuite/gas/i386/x86-64-apx-nf.s
@@ -1390,13 +1390,13 @@ optimize:
 	{nf}	\op	$128, %ecx, %edx
 	{nf}	\op	$128, %r9
 	{nf}	\op	$128, %r9, %r31
-	{nf}	\op\()b	$128, (%rax)
+	{nf}	\op\(b)	$128, (%rax)
 	{nf}	\op	$128, (%rax), %bl
-	{nf}	\op\()w	$128, (%rax)
+	{nf}	\op\(w)	$128, (%rax)
 	{nf}	\op	$128, (%rax), %dx
-	{nf}	\op\()l	$128, (%rax)
+	{nf}	\op\(l)	$128, (%rax)
 	{nf}	\op	$128, (%rax), %ecx
-	{nf}	\op\()q	$128, (%rax)
+	{nf}	\op\(q)	$128, (%rax)
 	{nf}	\op	$128, (%rax), %r9
 
 	{nf}	\op	$1, %bl
@@ -1407,13 +1407,13 @@ optimize:
 	{nf}	\op	$1, %ecx, %edx
 	{nf}	\op	$1, %r9
 	{nf}	\op	$1, %r9, %r31
-	{nf}	\op\()b	$1, (%rax)
+	{nf}	\op\(b)	$1, (%rax)
 	{nf}	\op	$1, (%rax), %bl
-	{nf}	\op\()w	$1, (%rax)
+	{nf}	\op\(w)	$1, (%rax)
 	{nf}	\op	$1, (%rax), %dx
-	{nf}	\op\()l	$1, (%rax)
+	{nf}	\op\(l)	$1, (%rax)
 	{nf}	\op	$1, (%rax), %ecx
-	{nf}	\op\()q	$1, (%rax)
+	{nf}	\op\(q)	$1, (%rax)
 	{nf}	\op	$1, (%rax), %r9
 
 	{nf}	\op	$0xff, %bl
@@ -1424,13 +1424,13 @@ optimize:
 	{nf}	\op	$-1, %ecx, %edx
 	{nf}	\op	$-1, %r9
 	{nf}	\op	$-1, %r9, %r31
-	{nf}	\op\()b	$0xff, (%rax)
+	{nf}	\op\(b)	$0xff, (%rax)
 	{nf}	\op	$-1, (%rax), %bl
-	{nf}	\op\()w	$0xffff, (%rax)
+	{nf}	\op\(w)	$0xffff, (%rax)
 	{nf}	\op	$-1, (%rax), %dx
-	{nf}	\op\()l	$0xffffffff, (%rax)
+	{nf}	\op\(l)	$0xffffffff, (%rax)
 	{nf}	\op	$-1, (%rax), %ecx
-	{nf}	\op\()q	$-1, (%rax)
+	{nf}	\op\(q)	$-1, (%rax)
 	{nf}	\op	$-1, (%rax), %r9
 	.endr
 
@@ -1444,13 +1444,13 @@ optimize:
 	{nf}	ro\dir	$63, %rdx
 	{nf}	ro\dir	$63, %rdx, %rax
 
-	{nf}	ro\dir\()b	$7, (%rdx)
+	{nf}	ro\dir\(b)	$7, (%rdx)
 	{nf}	ro\dir		$7, (%rdx), %al
-	{nf}	ro\dir\()w	$15, (%rdx)
+	{nf}	ro\dir\(w)	$15, (%rdx)
 	{nf}	ro\dir		$15, (%rdx), %ax
-	{nf}	ro\dir\()l	$31, (%rdx)
+	{nf}	ro\dir\(l)	$31, (%rdx)
 	{nf}	ro\dir		$31, (%rdx), %eax
-	{nf}	ro\dir\()q	$63, (%rdx)
+	{nf}	ro\dir\(q)	$63, (%rdx)
 	{nf}	ro\dir		$63, (%rdx), %rax
 	.endr
 
@@ -1476,10 +1476,10 @@ optimize:
 	# Note: 2-6 want leaving alone with -Os.
 	.irp n, 1, 2, 6, 7
 	# Note: 16-bit 3-operand src!=dst non-ZU form needs leaving alone.
-	{nf} imul $1<<\n, %\r\()dx, %\r\()cx
-	{nf} imul $1<<\n, (%rdx), %\r\()cx
-	{nf} imul $1<<\n, %\r\()cx, %\r\()cx
-	{nf} imul $1<<\n, %\r\()cx
+	{nf} imul $1<<\n, %\r\(dx), %\r\(cx)
+	{nf} imul $1<<\n, (%rdx), %\r\(cx)
+	{nf} imul $1<<\n, %\r\(cx), %\r\(cx)
+	{nf} imul $1<<\n, %\r\(cx)
 
 	.ifeqs "\r",""
 	{nf} imulzu $1<<\n, %dx, %cx
--- a/opcodes/cgen-asm.in
+++ b/opcodes/cgen-asm.in
@@ -68,6 +68,7 @@ char *
   char rxbuf[CGEN_MAX_RX_ELEMENTS];
   char *rx = rxbuf;
   const CGEN_SYNTAX_CHAR_TYPE *syn;
+  char prev_syntax_char = 0;
   int reg_err;
 
   syn = CGEN_SYNTAX_STRING (CGEN_OPCODE_SYNTAX (opc));
@@ -105,6 +106,15 @@ char *
 	{
 	  char c = CGEN_SYNTAX_CHAR (* syn);
 
+	  /* See whitespace related comments in parse_insn_normal().  */
+	  if (c != ' ' && prev_syntax_char != ' '
+	      && (!ISALNUM (c) || !ISALNUM (prev_syntax_char)))
+	    {
+	      *rx++ = ' ';
+	      *rx++ = '*';
+	    }
+	  prev_syntax_char = c;
+
 	  switch (c)
 	    {
 	      /* Escape any regex metacharacters in the syntax.  */
@@ -138,6 +148,7 @@ char *
 	  /* Replace non-syntax fields with globs.  */
 	  *rx++ = '.';
 	  *rx++ = '*';
+	  prev_syntax_char = 0;
 	}
     }
 
@@ -195,10 +206,8 @@ parse_insn_normal (CGEN_CPU_DESC cd,
   const char *errmsg;
   const char *p;
   const CGEN_SYNTAX_CHAR_TYPE * syn;
-#ifdef CGEN_MNEMONIC_OPERANDS
-  /* FIXME: wip */
-  int past_opcode_p;
-#endif
+  char prev_syntax_char = 0;
+  bool past_opcode_p;
 
   /* For now we assume the mnemonic is first (there are no leading operands).
      We can parse it without needing to set up operand parsing.
@@ -214,13 +223,13 @@ parse_insn_normal (CGEN_CPU_DESC cd,
 #ifndef CGEN_MNEMONIC_OPERANDS
   if (* str && ! ISSPACE (* str))
     return _("unrecognized instruction");
+  past_opcode_p = true;
+#else
+  past_opcode_p = false;
 #endif
 
   CGEN_INIT_PARSE (cd);
   cgen_init_parse_operand (cd);
-#ifdef CGEN_MNEMONIC_OPERANDS
-  past_opcode_p = 0;
-#endif
 
   /* We don't check for (*str != '\0') here because we want to parse
      any trailing fake arguments in the syntax string.  */
@@ -234,18 +243,28 @@ parse_insn_normal (CGEN_CPU_DESC cd,
 
   while (* syn != 0)
     {
+      char c = CGEN_SYNTAX_CHAR_P (*syn) ? CGEN_SYNTAX_CHAR (*syn) : 0;
+
+      /* FIXME: Despite this check we may still take inappropriate advantage of
+	 the fact that GAS's input scrubber will remove extraneous whitespace.
+	 We may also be a little too lax with this now, yet being more strict
+	 would require targets to indicate where whitespace is permissible.  */
+      if (past_opcode_p && c != ' ' && ISSPACE (*str)
+	  /* No whitespace between consecutive alphanumeric syntax elements.  */
+	  && (!ISALNUM (c) || !ISALNUM (prev_syntax_char)))
+	++str;
+      prev_syntax_char = c;
+
       /* Non operand chars must match exactly.  */
-      if (CGEN_SYNTAX_CHAR_P (* syn))
+      if (c != 0)
 	{
 	  /* FIXME: While we allow for non-GAS callers above, we assume the
 	     first char after the mnemonic part is a space.  */
-	  /* FIXME: We also take inappropriate advantage of the fact that
-	     GAS's input scrubber will remove extraneous blanks.  */
-	  if (TOLOWER (*str) == TOLOWER (CGEN_SYNTAX_CHAR (* syn)))
+	  if (TOLOWER (*str) == TOLOWER (c))
 	    {
 #ifdef CGEN_MNEMONIC_OPERANDS
-	      if (CGEN_SYNTAX_CHAR(* syn) == ' ')
-		past_opcode_p = 1;
+	      if (c == ' ')
+		past_opcode_p = true;
 #endif
 	      ++ syn;
 	      ++ str;
@@ -257,7 +276,7 @@ parse_insn_normal (CGEN_CPU_DESC cd,
 
 	      /* xgettext:c-format */
 	      sprintf (msg, _("syntax error (expected char `%c', found `%c')"),
-		       CGEN_SYNTAX_CHAR(*syn), *str);
+		       c, *str);
 	      return msg;
 	    }
 	  else
@@ -267,15 +286,12 @@ parse_insn_normal (CGEN_CPU_DESC cd,
 
 	      /* xgettext:c-format */
 	      sprintf (msg, _("syntax error (expected char `%c', found end of instruction)"),
-		       CGEN_SYNTAX_CHAR(*syn));
+		       c);
 	      return msg;
 	    }
 	  continue;
 	}
 
-#ifdef CGEN_MNEMONIC_OPERANDS
-      (void) past_opcode_p;
-#endif
       /* We have an operand of some sort.  */
       errmsg = cd->parse_operand (cd, CGEN_SYNTAX_FIELD (*syn), &str, fields);
       if (errmsg)
--- a/opcodes/nds32-asm.c
+++ b/opcodes/nds32-asm.c
@@ -2486,6 +2486,9 @@ parse_insn (nds32_asm_desc_t *pdesc, nds
 
       while (*plex)
 	{
+	  if (ISSPACE (*p))
+	    ++p;
+
 	  if (IS_LEX_CHAR (*plex))
 	    {
 	      /* If it's a plain char, just compare it.  */
@@ -2530,6 +2533,8 @@ parse_insn (nds32_asm_desc_t *pdesc, nds
 	}
 
       /* Check whether this syntax is accepted.  */
+      if (ISSPACE (*p))
+	++p;
       if (*plex == 0 && (*p == '\0' || *p == '!' || *p == '#'))
 	return 1;
 


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 00/17] gas: scrubber adjustments
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (16 preceding siblings ...)
  2024-07-12 13:18 ` [PATCH v2 17/17] gas: have scrubber retain more whitespace Jan Beulich
@ 2024-07-14 14:29 ` Alan Modra
  2024-07-17  0:13 ` Maciej W. Rozycki
  2024-07-19 13:22 ` [PATCH v2.5 01.5/17] x86: accept whitespace around prefix separator Jan Beulich
  19 siblings, 0 replies; 32+ messages in thread
From: Alan Modra @ 2024-07-14 14:29 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Anthony Green

On Fri, Jul 12, 2024 at 02:51:35PM +0200, Jan Beulich wrote:
> How is one supposed to have even the slightest idea whether a common
> code change breaks such a target (Cc-ing the two maintainers of the
> named targets which have one)?

I'm not at all worried about scrubber changes breaking spu.  The spu
assembler is written to not depend on whitespace being removed from
operands.

-- 
Alan Modra

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 05/17] gas: consistently drop trailing whitespace when scrubbing
  2024-07-12 13:00 ` [PATCH v2 05/17] gas: consistently drop trailing whitespace when scrubbing Jan Beulich
@ 2024-07-15 12:10   ` Maciej W. Rozycki
  0 siblings, 0 replies; 32+ messages in thread
From: Maciej W. Rozycki @ 2024-07-15 12:10 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Chenghua Xu

On Fri, 12 Jul 2024, Jan Beulich wrote:

> Leave respective comments as well, and update documentation to correct
> which comment form is actually replaced by a single blank (i.e. neither
> the ones starting with what {,tc_}comment_chars[] has nor the ones
> starting with what line_comment_chars[] has).

 For the MIPS parts:

Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk>

 Thank you for working on this.

  Maciej

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites
  2024-07-12 13:06 ` [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites Jan Beulich
@ 2024-07-15 12:11   ` Maciej W. Rozycki
  2024-07-15 14:08     ` Jan Beulich
  0 siblings, 1 reply; 32+ messages in thread
From: Maciej W. Rozycki @ 2024-07-15 12:11 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Chenghua Xu

On Fri, 12 Jul 2024, Jan Beulich wrote:

> Whitespace in macro arguments either needs quoting / parenthesizing to
> reliably not be mistaken for an argument separator, or respective macro
> parameters need to be marked as covering all remaining arguments. The
> former appears more appropriate here, as the macro parameters already
> have ":req".

 Thank you, however these macros interpret the argument as an arithmetic 
expression, so I think it will be more natural to parenthesise it rather 
than quote.  I note that this requirement is not documented in the GAS 
manual (or I cannot spot it).

  Maciej

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-12 13:11 ` [PATCH v2 15/17] MIPS: " Jan Beulich
@ 2024-07-15 12:12   ` Maciej W. Rozycki
  2024-07-15 14:22     ` Jan Beulich
  0 siblings, 1 reply; 32+ messages in thread
From: Maciej W. Rozycki @ 2024-07-15 12:12 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Chenghua Xu

On Fri, 12 Jul 2024, Jan Beulich wrote:

> In a subsequent change the scrubber is going to be changed to retain
> further whitespace. Test case expectations generally would better not
> depend on the specific whitespace treatment by the scrubber, unless of
> course a test is specifically about it. Adjust relevant test cases to
> permit blanks where those will subsequently appear.

 I disagree.  I understand you might be unhappy to have to tediously go 
and mechanically update a bunch of test cases because the spacing has 
changed (well, actually you don't have: you can just produce replacement 
dumps and just verify that the diff to the previous one is sane, which is 
what I do on such occasions).  But this is occasional effort, not expected 
to happen often, however the extra regexp characters make test patterns 
harder for a human to read.

 Therefore I would rather the updated patterns reflected new formatting 
verbatim, at least in the MIPS target I care about, and if we have a need 
to change formatting again in 10 years' time, then so be it.

> ---
> This is adding just the blanks that are going to be needed; imo it would
> generally be better if test case expectations were, from the very
> beginning, written to focus on what is being tested, rather than taking
> verbatim copies of the respective tool's output.

 I'm sorry, how could the test case writer predict that extra whitespace 
might be added in the future?  This statement makes no sense to me, this 
way all tests should be rewritten such as to possibly expect whitespace 
between tokens where there currently isn't any.

 Also I think if you retain whitespace, you should be doing this 
consistently, i.e. if the source instruction is say:

	dext	$2, $3, 1 << 2, 1 << 4

then in error reporting this should be used:

dext $2, $3, 1 << 2, 1 << 4

rather than this:

dext $2,$3,1 << 2,1 << 4

which makes the instruction reported hard to read/parse to a human, as you 
suddenly have whitespace within operands, but not between them.  I guess 
this is something to handle in 17/17.

 NAK for this part then.

  Maciej

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites
  2024-07-15 12:11   ` Maciej W. Rozycki
@ 2024-07-15 14:08     ` Jan Beulich
  0 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-15 14:08 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Binutils, Chenghua Xu

On 15.07.2024 14:11, Maciej W. Rozycki wrote:
> On Fri, 12 Jul 2024, Jan Beulich wrote:
> 
>> Whitespace in macro arguments either needs quoting / parenthesizing to
>> reliably not be mistaken for an argument separator, or respective macro
>> parameters need to be marked as covering all remaining arguments. The
>> former appears more appropriate here, as the macro parameters already
>> have ":req".
> 
>  Thank you, however these macros interpret the argument as an arithmetic 
> expression, so I think it will be more natural to parenthesise it rather 
> than quote.

Okay, I've changed it to that. Using quotes is overall cheaper parsing-
wise, but I'm absolutely going to respect your request. I won't re-post
just for this, though.

>  I note that this requirement is not documented in the GAS 
> manual (or I cannot spot it).

There's surprisingly little detail on how to (correctly and compatibly)
use / invoke macros. There's no mention at all on how to separate macro
arguments; the only hint is that macro parameters are explicitly
mentioned as being allowed to be only whitespace separated (by itself
already causing problems which aren't mentioned).

Jan


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 16/17] Sparc: relax gas testsuite whitespace expectations
  2024-07-12 13:12 ` [PATCH v2 16/17] Sparc: " Jan Beulich
@ 2024-07-15 14:17   ` Jose E. Marchesi
  0 siblings, 0 replies; 32+ messages in thread
From: Jose E. Marchesi @ 2024-07-15 14:17 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, David S. Miller


Hi Jan.
OK.  Thanks.

> In a subsequent change the scrubber is going to be changed to retain
> further whitespace. Test case expectations generally would better not
> depend on the specific whitespace treatment by the scrubber, unless of
> course a test is specifically about it. Adjust relevant test cases to
> permit blanks where those will subsequently appear.
> ---
> This is adding just the blank that is going to be needed; imo it would
> generally be better if test case expectations were, from the very
> beginning, written to focus on what is being tested, rather than taking
> verbatim copies of the respective tool's output.
> ---
> v2: New.
>
> --- a/gas/testsuite/gas/sparc/asi-arch-error.l
> +++ b/gas/testsuite/gas/sparc/asi-arch-error.l
> @@ -1,3 +1,3 @@
>  .*asi-arch-error.s: Assembler messages:
> -.*asi-arch-error.s:3: Error: Architecture mismatch on "ldda \[%g0]#ASI_FL16_P,%f0".
> +.*asi-arch-error.s:3: Error: Architecture mismatch on "ldda \[%g0] ?#ASI_FL16_P,%f0".
>  .*asi-arch-error.s:3: \(Requires v9b\|v9c\|v9d\|v9e\|v9v\|v9m.*; requested architecture is v9.\)

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-15 12:12   ` Maciej W. Rozycki
@ 2024-07-15 14:22     ` Jan Beulich
  2024-07-17  0:09       ` Maciej W. Rozycki
  0 siblings, 1 reply; 32+ messages in thread
From: Jan Beulich @ 2024-07-15 14:22 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Binutils, Chenghua Xu

On 15.07.2024 14:12, Maciej W. Rozycki wrote:
> On Fri, 12 Jul 2024, Jan Beulich wrote:
> 
>> In a subsequent change the scrubber is going to be changed to retain
>> further whitespace. Test case expectations generally would better not
>> depend on the specific whitespace treatment by the scrubber, unless of
>> course a test is specifically about it. Adjust relevant test cases to
>> permit blanks where those will subsequently appear.
> 
>  I disagree.  I understand you might be unhappy to have to tediously go 
> and mechanically update a bunch of test cases because the spacing has 
> changed (well, actually you don't have: you can just produce replacement 
> dumps and just verify that the diff to the previous one is sane, which is 
> what I do on such occasions).  But this is occasional effort, not expected 
> to happen often, however the extra regexp characters make test patterns 
> harder for a human to read.
> 
>  Therefore I would rather the updated patterns reflected new formatting 
> verbatim, at least in the MIPS target I care about, and if we have a need 
> to change formatting again in 10 years' time, then so be it.

Which then means these changes here need to be part of the patch actually
changing the scrubber. I can do that, but I'd like to point out the
scalability issue with this: If all arch maintainers asked me to do so,
I'd end up with a gigantic patch.

>> ---
>> This is adding just the blanks that are going to be needed; imo it would
>> generally be better if test case expectations were, from the very
>> beginning, written to focus on what is being tested, rather than taking
>> verbatim copies of the respective tool's output.
> 
>  I'm sorry, how could the test case writer predict that extra whitespace 
> might be added in the future?

This is the wrong question to ask, imo. There's no whitespace being
"added". The issue is with listing tests which take verbatim the listing
output, when really they should further consider the original input to
gas. In principle any whitespace there may or may not survive scrubbing.

>  This statement makes no sense to me, this 
> way all tests should be rewritten such as to possibly expect whitespace 
> between tokens where there currently isn't any.

Listing tests should indeed have been written like this, imo.

>  Also I think if you retain whitespace, you should be doing this 
> consistently, i.e. if the source instruction is say:
> 
> 	dext	$2, $3, 1 << 2, 1 << 4
> 
> then in error reporting this should be used:
> 
> dext $2, $3, 1 << 2, 1 << 4
> 
> rather than this:
> 
> dext $2,$3,1 << 2,1 << 4
> 
> which makes the instruction reported hard to read/parse to a human, as you 
> suddenly have whitespace within operands, but not between them.  I guess 
> this is something to handle in 17/17.

No. I'm very deliberately special casing commas there, or else I'd have
to make yet more adjustments to the testsuite. It's already bad enough.
Plus who knows how many more target specific parsing adjustments I'd need
to make, to deal with the further "surviving" whitespace.

(As an aside, I'm also having trouble seeing why the whole insn, with all
operands, would need quoting in a diagnostic. There may be rare cases
whether this is necessary for context, but usually it should be sufficient
to mention just the part that's actually wrong.)

>  NAK for this part then.

I'm sorry, but no, I'm not going to drop all this work just because of you
not liking a tiny aspect. Best I can do then is to leave out this patch,
and leave fixing the MIPS testsuite to you. I'm not sure you're going to
be happy about this. Please let me know.

Jan

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-15 14:22     ` Jan Beulich
@ 2024-07-17  0:09       ` Maciej W. Rozycki
  2024-07-17 10:40         ` Jan Beulich
  0 siblings, 1 reply; 32+ messages in thread
From: Maciej W. Rozycki @ 2024-07-17  0:09 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Chenghua Xu

On Mon, 15 Jul 2024, Jan Beulich wrote:

> >  Therefore I would rather the updated patterns reflected new formatting 
> > verbatim, at least in the MIPS target I care about, and if we have a need 
> > to change formatting again in 10 years' time, then so be it.
> 
> Which then means these changes here need to be part of the patch actually
> changing the scrubber. I can do that, but I'd like to point out the
> scalability issue with this: If all arch maintainers asked me to do so,
> I'd end up with a gigantic patch.

 That's true.

> >> ---
> >> This is adding just the blanks that are going to be needed; imo it would
> >> generally be better if test case expectations were, from the very
> >> beginning, written to focus on what is being tested, rather than taking
> >> verbatim copies of the respective tool's output.
> > 
> >  I'm sorry, how could the test case writer predict that extra whitespace 
> > might be added in the future?
> 
> This is the wrong question to ask, imo. There's no whitespace being
> "added". The issue is with listing tests which take verbatim the listing
> output, when really they should further consider the original input to
> gas. In principle any whitespace there may or may not survive scrubbing.

 Fair enough, but see my next reply below.

> >  This statement makes no sense to me, this 
> > way all tests should be rewritten such as to possibly expect whitespace 
> > between tokens where there currently isn't any.
> 
> Listing tests should indeed have been written like this, imo.

 It is often impractical and such listings are typically obtained from the 
tool directly, examined to verify that they match expectations, and then 
possibly tweaked a little by hand.  So there's usually little actual 
"writing" involved.

> >  Also I think if you retain whitespace, you should be doing this 
> > consistently, i.e. if the source instruction is say:
> > 
> > 	dext	$2, $3, 1 << 2, 1 << 4
> > 
> > then in error reporting this should be used:
> > 
> > dext $2, $3, 1 << 2, 1 << 4
> > 
> > rather than this:
> > 
> > dext $2,$3,1 << 2,1 << 4
> > 
> > which makes the instruction reported hard to read/parse to a human, as you 
> > suddenly have whitespace within operands, but not between them.  I guess 
> > this is something to handle in 17/17.
> 
> No. I'm very deliberately special casing commas there, or else I'd have
> to make yet more adjustments to the testsuite. It's already bad enough.
> Plus who knows how many more target specific parsing adjustments I'd need
> to make, to deal with the further "surviving" whitespace.

 Understood, that's a practical argument.  I wonder if it would make sense 
to do additional scrubbing just for reporting.

> (As an aside, I'm also having trouble seeing why the whole insn, with all
> operands, would need quoting in a diagnostic. There may be rare cases
> whether this is necessary for context, but usually it should be sufficient
> to mention just the part that's actually wrong.)

 It would require extra processing.  GAS doesn't actually know which part 
of the instruction is wrong: it's got rejected by opcodes, because it 
didn't match any existing instruction+operand set pattern.  It does know 
if it was the mnemonic or the operands and reports that with the message 
preceding the instruction quoted, but I think there's little if any value 
in removing parts of the instruction.  Contrariwise, I think that would 
actually only obfuscate things.

 And then even if GAS knew the details of the problematic operands there 
may be ambiguity, such as where each of the operands might be OK as long 
as the other one was different.

 Consider this instruction:

	bltc	$2, $2, .

$ mips-linux-gnu-as -mips32r6 -o bltc.o bltc.s
bltc.s: Assembler messages:
bltc.s:1: Error: invalid operands `bltc $2,$2,.'
$ 

It gets rejected because both register operands refer to the same 
register, in which case it would be a different machine instruction if 
that was actually let through and encoded (i.e. "bltzc $2, .").

 But there's nothing wrong with either operand, it's the combination of 
the operands that doesn't work, and opcodes don't share this information. 
It's buried deep down in the opcode table interpreter, which tries all the 
entries in turn that match the mnemonic to see if the operand pattern 
matches and gives up once it's run out of the entries and none of the 
patterns matched the operands.

 So from the error message above you know it's operands that are wrong and 
you need to figure out on your own what is actually wrong with them.

 I guess opcodes could pass some details up, which could then be processed
by GAS, but given what I have written above it's not clear to me that it's 
worth the effort.

> >  NAK for this part then.
> 
> I'm sorry, but no, I'm not going to drop all this work just because of you
> not liking a tiny aspect. Best I can do then is to leave out this patch,
> and leave fixing the MIPS testsuite to you. I'm not sure you're going to
> be happy about this. Please let me know.

 I'm happy to make such an update myself, that's not a problem, but let me 
chew it over yet.  If anything I suppose using `*' rather than `?' would 
be more future-proof, but then again, maybe it doesn't matter?

 In any case I'll wait for the review outcome for the generic parts and 
then I can decide what to do about the MIPS port.

 In any case thank you for your input and your effort in the first place.

  Maciej

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 00/17] gas: scrubber adjustments
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (17 preceding siblings ...)
  2024-07-14 14:29 ` [PATCH v2 00/17] gas: scrubber adjustments Alan Modra
@ 2024-07-17  0:13 ` Maciej W. Rozycki
  2024-07-21 20:15   ` VAX test coverage (was: [PATCH v2 00/17] gas: scrubber adjustments) Jan-Benedict Glaw
  2024-07-19 13:22 ` [PATCH v2.5 01.5/17] x86: accept whitespace around prefix separator Jan Beulich
  19 siblings, 1 reply; 32+ messages in thread
From: Maciej W. Rozycki @ 2024-07-17  0:13 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Anthony Green, Alan Modra, Jan-Benedict Glaw

On Fri, 12 Jul 2024, Jan Beulich wrote:

> named targets which have one)? I'm already worried enough by targets
> having only a pretty "slim" set of test cases. In any event, target

 I am actually very unhappy with the state of the VAX target in this 
respect, which I do care about from the GCC side.  But that's a technical 
debt accumulated over decades, which requires considerable effort to pay 
back, which would have been much easier to handle if it had been spread 
across all those years.

 I've been meaning at least to add a list of all the assembly instructions 
and then some coverage for the rich set of addressing modes, but there's 
always been something more urgent to do.  Cc-ing the active VAX maintainer 
in case he feels compelled to do some of this work.

  Maciej

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-17  0:09       ` Maciej W. Rozycki
@ 2024-07-17 10:40         ` Jan Beulich
  2024-07-30 23:58           ` Maciej W. Rozycki
  0 siblings, 1 reply; 32+ messages in thread
From: Jan Beulich @ 2024-07-17 10:40 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Binutils, Chenghua Xu

On 17.07.2024 02:09, Maciej W. Rozycki wrote:
> On Mon, 15 Jul 2024, Jan Beulich wrote:
>>>> ---
>>>> This is adding just the blanks that are going to be needed; imo it would
>>>> generally be better if test case expectations were, from the very
>>>> beginning, written to focus on what is being tested, rather than taking
>>>> verbatim copies of the respective tool's output.
>>>
>>>  I'm sorry, how could the test case writer predict that extra whitespace 
>>> might be added in the future?
>>
>> This is the wrong question to ask, imo. There's no whitespace being
>> "added". The issue is with listing tests which take verbatim the listing
>> output, when really they should further consider the original input to
>> gas. In principle any whitespace there may or may not survive scrubbing.
> 
>  Fair enough, but see my next reply below.
> 
>>>  This statement makes no sense to me, this 
>>> way all tests should be rewritten such as to possibly expect whitespace 
>>> between tokens where there currently isn't any.
>>
>> Listing tests should indeed have been written like this, imo.
> 
>  It is often impractical and such listings are typically obtained from the 
> tool directly, examined to verify that they match expectations, and then 
> possibly tweaked a little by hand.  So there's usually little actual 
> "writing" involved.

I certainly understand why listing tests are done the way they are. It's
much easier and faster to simply take the output of a tool. Yet that's
my whole point: Doing so is deferring the work to someone else, later on.
It's not the first time I'm ending up as the one paying the price.

>>>  Also I think if you retain whitespace, you should be doing this 
>>> consistently, i.e. if the source instruction is say:
>>>
>>> 	dext	$2, $3, 1 << 2, 1 << 4
>>>
>>> then in error reporting this should be used:
>>>
>>> dext $2, $3, 1 << 2, 1 << 4
>>>
>>> rather than this:
>>>
>>> dext $2,$3,1 << 2,1 << 4
>>>
>>> which makes the instruction reported hard to read/parse to a human, as you 
>>> suddenly have whitespace within operands, but not between them.  I guess 
>>> this is something to handle in 17/17.
>>
>> No. I'm very deliberately special casing commas there, or else I'd have
>> to make yet more adjustments to the testsuite. It's already bad enough.
>> Plus who knows how many more target specific parsing adjustments I'd need
>> to make, to deal with the further "surviving" whitespace.
> 
>  Understood, that's a practical argument.  I wonder if it would make sense 
> to do additional scrubbing just for reporting.

That's certainly a possibility. But see below.

>> (As an aside, I'm also having trouble seeing why the whole insn, with all
>> operands, would need quoting in a diagnostic. There may be rare cases
>> whether this is necessary for context, but usually it should be sufficient
>> to mention just the part that's actually wrong.)
> 
>  It would require extra processing.  GAS doesn't actually know which part 
> of the instruction is wrong: it's got rejected by opcodes, because it 
> didn't match any existing instruction+operand set pattern.

That's a MIPS-specific thing then, I suppose? x86 for example parses
operands all in gas, and each one separately. And it goes to some lengths
to provide useful (read: as specific as possible) diagnostics. Which
isn't to say there wouldn't still be a lot of room for improvement.

Yet then, looking at tc-mips.c, I can't help getting the impression that
arguments are parsed individually there, too. For the result to then be
handed to match_insns().

>  It does know 
> if it was the mnemonic or the operands and reports that with the message 
> preceding the instruction quoted, but I think there's little if any value 
> in removing parts of the instruction.  Contrariwise, I think that would 
> actually only obfuscate things.
> 
>  And then even if GAS knew the details of the problematic operands there 
> may be ambiguity, such as where each of the operands might be OK as long 
> as the other one was different.
> 
>  Consider this instruction:
> 
> 	bltc	$2, $2, .
> 
> $ mips-linux-gnu-as -mips32r6 -o bltc.o bltc.s
> bltc.s: Assembler messages:
> bltc.s:1: Error: invalid operands `bltc $2,$2,.'
> $ 
> 
> It gets rejected because both register operands refer to the same 
> register, in which case it would be a different machine instruction if 
> that was actually let through and encoded (i.e. "bltzc $2, .").
> 
>  But there's nothing wrong with either operand, it's the combination of 
> the operands that doesn't work, and opcodes don't share this information. 
> It's buried deep down in the opcode table interpreter, which tries all the 
> entries in turn that match the mnemonic to see if the operand pattern 
> matches and gives up once it's run out of the entries and none of the 
> patterns matched the operands.
> 
>  So from the error message above you know it's operands that are wrong and 
> you need to figure out on your own what is actually wrong with them.
> 
>  I guess opcodes could pass some details up, which could then be processed
> by GAS, but given what I have written above it's not clear to me that it's 
> worth the effort.

Well, I can certainly see that there's a question of balancing effort to
provide better diagnostics against how often people would actually care.

>>>  NAK for this part then.
>>
>> I'm sorry, but no, I'm not going to drop all this work just because of you
>> not liking a tiny aspect. Best I can do then is to leave out this patch,
>> and leave fixing the MIPS testsuite to you. I'm not sure you're going to
>> be happy about this. Please let me know.
> 
>  I'm happy to make such an update myself, that's not a problem, but let me 
> chew it over yet.  If anything I suppose using `*' rather than `?' would 
> be more future-proof, but then again, maybe it doesn't matter?

If * was wanted (needed), that would be an indication of the scrubber doing
almost nothing at all. That's certainly a theoretical possibility, but I
don't think it's one in practice. Unless we were to effectively drop all
scrubbing.

Jan

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH v2.5 01.5/17] x86: accept whitespace around prefix separator
  2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
                   ` (18 preceding siblings ...)
  2024-07-17  0:13 ` Maciej W. Rozycki
@ 2024-07-19 13:22 ` Jan Beulich
  19 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-19 13:22 UTC (permalink / raw)
  To: Binutils; +Cc: H.J. Lu

... and prediction suffix comma. Other than documented /**/ comments
currently aren't really converted to a single space, at least not for
x86 in its most common configurations. That'll be fixed subsequently, at
which point blanks may appear where so far none were expected.
Furthermore not permitting blanks around these separators wasn't quite
logical anyway - such constructs are composite ones, and hence
components ought to have been permitted to be separated by whitespace
from the very beginning. Furthermore note how, due to the scrubber being
overly aggressive in removing whitespace, some similar construct with a
prefix were already accepted.

Note how certain other checks in parse_insn() can be simplified as a
result.

While there for the prediction suffix also make checks case-insensitive
and check for a proper trailing separator.
---
v2.5: New.

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -7958,6 +7958,8 @@ parse_insn (const char *line, char *mnem
 
   while (1)
     {
+      const char *split;
+
       mnem_p = mnemonic;
       /* Pseudo-prefixes start with an opening figure brace.  */
       if ((*mnem_p = *l) == '{')
@@ -7982,9 +7984,10 @@ parse_insn (const char *line, char *mnem
 	    }
 	  l++;
 	}
-      /* Pseudo-prefixes end with a closing figure brace.  */
-      if (*mnemonic == '{' && is_space_char (*l))
+      split = l;
+      if (is_space_char (*l))
 	++l;
+      /* Pseudo-prefixes end with a closing figure brace.  */
       if (*mnemonic == '{' && *l == '}')
 	{
 	  *mnem_p++ = *l++;
@@ -7992,12 +7995,10 @@ parse_insn (const char *line, char *mnem
 	    goto too_long;
 	  *mnem_p = '\0';
 
-	  /* Point l at the closing brace if there's no other separator.  */
-	  if (*l != END_OF_INSN && !is_space_char (*l)
-	      && *l != PREFIX_SEPARATOR)
-	    --l;
+	  if (is_space_char (*l))
+	    ++l;
 	}
-      else if (!is_space_char (*l)
+      else if (l == split
 	       && *l != END_OF_INSN
 	       && (intel_syntax
 		   || (*l != PREFIX_SEPARATOR && *l != ',')))
@@ -8005,7 +8006,7 @@ parse_insn (const char *line, char *mnem
 	  if (mode != parse_all)
 	    break;
 	  as_bad (_("invalid character %s in mnemonic"),
-		  output_invalid (*l));
+		  output_invalid (*split));
 	  return NULL;
 	}
       if (token_start == l)
@@ -8021,7 +8022,6 @@ parse_insn (const char *line, char *mnem
       op_lookup (mnemonic);
 
       if (*l != END_OF_INSN
-	  && (!is_space_char (*l) || l[1] != END_OF_INSN)
 	  && current_templates.start
 	  && current_templates.start->opcode_modifier.isprefix)
 	{
@@ -8143,7 +8143,10 @@ parse_insn (const char *line, char *mnem
 		}
 	    }
 	  /* Skip past PREFIX_SEPARATOR and reset token_start.  */
-	  token_start = ++l;
+	  l += (!intel_syntax && *l == PREFIX_SEPARATOR);
+	  if (is_space_char (*l))
+	    ++l;
+	  token_start = l;
 	}
       else
 	break;
@@ -8235,8 +8238,7 @@ parse_insn (const char *line, char *mnem
 		}
 	      /* For compatibility reasons accept MOVSD and CMPSD without
 	         operands even in AT&T mode.  */
-	      else if (*l == END_OF_INSN
-		       || (is_space_char (*l) && l[1] == END_OF_INSN))
+	      else if (*l == END_OF_INSN)
 		{
 		  mnem_p[-1] = '\0';
 		  op_lookup (mnemonic);
@@ -8278,8 +8280,9 @@ parse_insn (const char *line, char *mnem
       l += length;
     }
 
-  if (current_templates.start->opcode_modifier.jump == JUMP
-      || current_templates.start->opcode_modifier.jump == JUMP_BYTE)
+  if ((current_templates.start->opcode_modifier.jump == JUMP
+       || current_templates.start->opcode_modifier.jump == JUMP_BYTE)
+      && *l == ',')
     {
       /* Check for a branch hint.  We allow ",pt" and ",pn" for
 	 predict taken and predict not taken respectively.
@@ -8287,21 +8290,29 @@ parse_insn (const char *line, char *mnem
 	 and jcxz insns (JumpByte) for current Pentium4 chips.  They
 	 may work in the future and it doesn't hurt to accept them
 	 now.  */
-      if (l[0] == ',' && l[1] == 'p')
+      token_start = l++;
+      if (is_space_char (*l))
+	++l;
+      if (TOLOWER (*l) == 'p' && ISALPHA (l[1])
+	  && (l[2] == END_OF_INSN || is_space_char (l[2])))
 	{
-	  if (l[2] == 't')
+	  if (TOLOWER (l[1]) == 't')
 	    {
 	      if (!add_prefix (DS_PREFIX_OPCODE))
 		return NULL;
-	      l += 3;
+	      l += 2;
 	    }
-	  else if (l[2] == 'n')
+	  else if (TOLOWER (l[1]) == 'n')
 	    {
 	      if (!add_prefix (CS_PREFIX_OPCODE))
 		return NULL;
-	      l += 3;
+	      l += 2;
 	    }
+	  else
+	    l = token_start;
 	}
+      else
+	l = token_start;
     }
   /* Any other comma loses.  */
   if (*l == ',')
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -106,6 +106,7 @@ if [gas_32_check] then {
     run_list_test "equ-2" "-al"
     run_list_test "equ-bad"
     run_dump_test "curly"
+    run_dump_test "separator"
     run_dump_test "divide"
     run_dump_test "quoted"
     run_dump_test "quoted2"
--- /dev/null
+++ b/gas/testsuite/gas/i386/separator.d
@@ -0,0 +1,27 @@
+#objdump: -dw
+#name: whitespace around special separators
+
+.*: +file format .*
+
+Disassembly of section \.text:
+
+0+ <separators>:
+[ 	]*[a-f0-9]+:	3e 72 fd +	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 72 fd +	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 72 fd +	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 72 fd +	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 72 fd +	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 0f 82 f9 ff ff ff 	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 0f 82 f9 ff ff ff 	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 0f 82 f9 ff ff ff 	j[cb],pt .*
+[ 	]*[a-f0-9]+:	3e 0f 82 f9 ff ff ff 	j[cb],pt .*
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+[ 	]*[a-f0-9]+:	65 f7 d8 +	gs neg %eax
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/separator.s
@@ -0,0 +1,41 @@
+	.text
+separators:
+	jc,pt		.
+	jc ,pt		.
+	jc, pt		.
+	jc , pt		.
+	jc/**/,/**/pt	.
+
+	{disp32} jc,pt	.
+	{disp32} jc ,pt .
+	{disp32} jc, pt .
+	{disp32} jc , pt .
+
+	# Which block to use depends on whether / starts a comment.
+	.ifeq 1/2
+
+	gs/neg	%eax
+	gs /neg	%eax
+	gs/ neg	%eax
+	gs / neg %eax
+	gs/**///**/neg %eax
+
+	{disp32} gs/neg %eax
+	{disp32} gs /neg %eax
+	{disp32} gs/ neg %eax
+	{disp32} gs / neg %eax
+
+	.else
+
+	gs\neg	%eax
+	gs \neg	%eax
+	gs\ neg	%eax
+	gs \ neg %eax
+	gs/**/\/**/neg %eax
+
+	{disp32} gs\neg %eax
+	{disp32} gs \neg %eax
+	{disp32} gs\ neg %eax
+	{disp32} gs \ neg %eax
+
+	.endif


^ permalink raw reply	[flat|nested] 32+ messages in thread

* VAX test coverage (was: [PATCH v2 00/17] gas: scrubber adjustments)
  2024-07-17  0:13 ` Maciej W. Rozycki
@ 2024-07-21 20:15   ` Jan-Benedict Glaw
  0 siblings, 0 replies; 32+ messages in thread
From: Jan-Benedict Glaw @ 2024-07-21 20:15 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Jan Beulich, Binutils, Anthony Green, Alan Modra

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Wed, 2024-07-17 01:13:04 +0100, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>  I am actually very unhappy with the state of the VAX target in this 
> respect, which I do care about from the GCC side.  But that's a technical 
> debt accumulated over decades, which requires considerable effort to pay 
> back, which would have been much easier to handle if it had been spread 
> across all those years.
> 
>  I've been meaning at least to add a list of all the assembly instructions 
> and then some coverage for the rich set of addressing modes, but there's 
> always been something more urgent to do.  Cc-ing the active VAX maintainer 
> in case he feels compelled to do some of this work.

Opcodes, adressing modes, maybe pseudo opcodes and better handling of
specifically typed (f, d, g, h) to match the opcode (at least for
immediates.) I'll see if I can prepare something during these days.

MfG, JBG

-- 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-17 10:40         ` Jan Beulich
@ 2024-07-30 23:58           ` Maciej W. Rozycki
  2024-07-31 10:14             ` Jan Beulich
  0 siblings, 1 reply; 32+ messages in thread
From: Maciej W. Rozycki @ 2024-07-30 23:58 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Binutils, Chenghua Xu

On Wed, 17 Jul 2024, Jan Beulich wrote:

> >  It is often impractical and such listings are typically obtained from the 
> > tool directly, examined to verify that they match expectations, and then 
> > possibly tweaked a little by hand.  So there's usually little actual 
> > "writing" involved.
> 
> I certainly understand why listing tests are done the way they are. It's
> much easier and faster to simply take the output of a tool. Yet that's
> my whole point: Doing so is deferring the work to someone else, later on.
> It's not the first time I'm ending up as the one paying the price.

 Sorry for where I caused you extra work, certainly not intended.

> >  It would require extra processing.  GAS doesn't actually know which part 
> > of the instruction is wrong: it's got rejected by opcodes, because it 
> > didn't match any existing instruction+operand set pattern.
> 
> That's a MIPS-specific thing then, I suppose? x86 for example parses
> operands all in gas, and each one separately. And it goes to some lengths
> to provide useful (read: as specific as possible) diagnostics. Which
> isn't to say there wouldn't still be a lot of room for improvement.

 I don't know the x86 machinery, but even there from the instruction set 
itself, which I used to be familiar with up to a point, I know that some 
instructions accept various operands that need to match certain patterns.

> Yet then, looking at tc-mips.c, I can't help getting the impression that
> arguments are parsed individually there, too. For the result to then be
> handed to match_insns().

 Operands are necessarily parsed by GAS, but at this point all that can 
be done is to make sure that an operand itself is well-formed and figure 
out what it is, i.e. a register, an immediate, a symbol, etc. and not 
whether it fits the instruction being assembled.  Certain combinations of 
individually valid operands might be OK and other ones will not, and it's 
up to opcodes to figure out.

 So speaking in x86 terms, e.g. a debug register reference is a valid
operand, but only to the MOV instruction, and then only combined with a 
GPR operand, which has to be the sole other operand, but then in any order 
between the two.  Is it handled all within GAS without referring to 
opcodes by the x86 port?

 And if you have say "mov %db6, %db7" in your assembly source, then how do
you determine which of the two operands is wrong?

 In the MIPS opcode tables these operations could be recorded as say:

{ "mov", "g,d", ...
{ "mov", "d,g", ...

where "g" and "d" stand for respectively a general-purpose and a debug 
register, and "," is literal comma, and then what follows marked as "..." 
and omitted above tells the machine code producer how to encode the fixed 
part of the instruction word and what microarchitecures the instruction is 
valid for.  When matched against the invalid instruction quoted in the 
previous paragraph these opcode table entries will only tell GAS that 
neither was a hit, and won't tell which of the two operands was not right.  
And the ultimate answer is: either.

 Of course there'd be another entry too:

{ "mov", "d,d", ...

for the x86's inter-GPR move instruction, which would also be matched 
against (and miss with the instruction discussed here).

> >  So from the error message above you know it's operands that are wrong and 
> > you need to figure out on your own what is actually wrong with them.
> > 
> >  I guess opcodes could pass some details up, which could then be processed
> > by GAS, but given what I have written above it's not clear to me that it's 
> > worth the effort.
> 
> Well, I can certainly see that there's a question of balancing effort to
> provide better diagnostics against how often people would actually care.

 I think it's actually better to give vaguer diagnostics which forces the 
developer to think about the cause rather than more precise but possibly 
incorrect one.

 And it's not that there is a lot of information to parse: you typically 
have 2-3, sometimes 4 operands to an assembly instruction and you can 
refer the assembly language programming manual or, in the absence of one, 
the architecture manual for your target to figure out what instruction 
forms have been defined.

> >  I'm happy to make such an update myself, that's not a problem, but let me 
> > chew it over yet.  If anything I suppose using `*' rather than `?' would 
> > be more future-proof, but then again, maybe it doesn't matter?
> 
> If * was wanted (needed), that would be an indication of the scrubber doing
> almost nothing at all. That's certainly a theoretical possibility, but I
> don't think it's one in practice. Unless we were to effectively drop all
> scrubbing.

 So I have given it further consideration and came to the conclusion that 
we ought to go for the " ?" variant now for the sake of keeping test 
results clean across scrubber updates, and I can try identifying potential 
further places that such a change will be desirable for.  However once the 
scrubber has settled I'd rather remove the variants and switch solely to
new formatting.

 In a recent MIPS testsuite cleanup I actually removed a bunch of obsolete 
variant patterns, because it makes no sense to carry such baggage along 10 
or 20 years since the old matches have become irrelevant and moreover for 
consistency I'd have to artificially add them to new dumps that cover new 
code that has never produced them, which would make even less sense.

  Maciej

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH v2 15/17] MIPS: relax gas testsuite whitespace expectations
  2024-07-30 23:58           ` Maciej W. Rozycki
@ 2024-07-31 10:14             ` Jan Beulich
  0 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2024-07-31 10:14 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Binutils, Chenghua Xu

On 31.07.2024 01:58, Maciej W. Rozycki wrote:
> On Wed, 17 Jul 2024, Jan Beulich wrote:
>>>  It would require extra processing.  GAS doesn't actually know which part 
>>> of the instruction is wrong: it's got rejected by opcodes, because it 
>>> didn't match any existing instruction+operand set pattern.
>>
>> That's a MIPS-specific thing then, I suppose? x86 for example parses
>> operands all in gas, and each one separately. And it goes to some lengths
>> to provide useful (read: as specific as possible) diagnostics. Which
>> isn't to say there wouldn't still be a lot of room for improvement.
> 
>  I don't know the x86 machinery, but even there from the instruction set 
> itself, which I used to be familiar with up to a point, I know that some 
> instructions accept various operands that need to match certain patterns.
> 
>> Yet then, looking at tc-mips.c, I can't help getting the impression that
>> arguments are parsed individually there, too. For the result to then be
>> handed to match_insns().
> 
>  Operands are necessarily parsed by GAS, but at this point all that can 
> be done is to make sure that an operand itself is well-formed and figure 
> out what it is, i.e. a register, an immediate, a symbol, etc. and not 
> whether it fits the instruction being assembled.  Certain combinations of 
> individually valid operands might be OK and other ones will not, and it's 
> up to opcodes to figure out.
> 
>  So speaking in x86 terms, e.g. a debug register reference is a valid
> operand, but only to the MOV instruction, and then only combined with a 
> GPR operand, which has to be the sole other operand, but then in any order 
> between the two.  Is it handled all within GAS without referring to 
> opcodes by the x86 port?
> 
>  And if you have say "mov %db6, %db7" in your assembly source, then how do
> you determine which of the two operands is wrong?

You simply can't, because you can't know what the programmer meant. To
diagnose this, it isn't necessary to quote the entire insn + operands
in the diagnostic, though. There's one case in Arm64 code where I can
see why quoting operands can be useful: They have cases where they
try to guess what may have been meant, listing the guessed alternatives
alongside the actual diagnostic.

>  In the MIPS opcode tables these operations could be recorded as say:
> 
> { "mov", "g,d", ...
> { "mov", "d,g", ...
> 
> where "g" and "d" stand for respectively a general-purpose and a debug 
> register, and "," is literal comma, and then what follows marked as "..." 
> and omitted above tells the machine code producer how to encode the fixed 
> part of the instruction word and what microarchitecures the instruction is 
> valid for.  When matched against the invalid instruction quoted in the 
> previous paragraph these opcode table entries will only tell GAS that 
> neither was a hit, and won't tell which of the two operands was not right.  
> And the ultimate answer is: either.

Right, which supports my view that quoting the full insn+operands isn't
helpful in such a case.

>>>  I'm happy to make such an update myself, that's not a problem, but let me 
>>> chew it over yet.  If anything I suppose using `*' rather than `?' would 
>>> be more future-proof, but then again, maybe it doesn't matter?
>>
>> If * was wanted (needed), that would be an indication of the scrubber doing
>> almost nothing at all. That's certainly a theoretical possibility, but I
>> don't think it's one in practice. Unless we were to effectively drop all
>> scrubbing.
> 
>  So I have given it further consideration and came to the conclusion that 
> we ought to go for the " ?" variant now for the sake of keeping test 
> results clean across scrubber updates, and I can try identifying potential 
> further places that such a change will be desirable for.  However once the 
> scrubber has settled I'd rather remove the variants and switch solely to
> new formatting.

Thanks. I'm about to post v3, and I don't intend to wait much longer with
committing, unless of course I get objections or comments requiring further
updates to the series.

Jan

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2024-07-31 10:14 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-12 12:51 [PATCH v2 00/17] gas: scrubber adjustments Jan Beulich
2024-07-12 12:56 ` [PATCH v2 01/17] x86: accept whitespace inside curly braces Jan Beulich
2024-07-12 12:57 ` [PATCH v2 02/17] gas: drop scrubber state -2 Jan Beulich
2024-07-12 12:57 ` [PATCH v2 03/17] gas: pre-init the scrubber's lex[] Jan Beulich
2024-07-12 12:58 ` [PATCH v2 04/17] gas: drop tic6x scrubber special case Jan Beulich
2024-07-12 13:00 ` [PATCH v2 05/17] gas: consistently drop trailing whitespace when scrubbing Jan Beulich
2024-07-15 12:10   ` Maciej W. Rozycki
2024-07-12 13:01 ` [PATCH v2 06/17] gas: adjust impossible/bogus M68K/MRI special case " Jan Beulich
2024-07-12 13:02 ` [PATCH v2 07/17] Arm: correct macro use in gas testsuite Jan Beulich
2024-07-12 13:03 ` [PATCH v2 08/17] bfin: " Jan Beulich
2024-07-12 13:04 ` [PATCH v2 09/17] bfin: drop _ASSIGN_BANG Jan Beulich
2024-07-12 13:05 ` [PATCH v2 10/17] ia64: correct macro use in gas testsuite Jan Beulich
2024-07-12 13:06 ` [PATCH v2 11/17] MIPS: correct macro use in gas and ld testsuites Jan Beulich
2024-07-15 12:11   ` Maciej W. Rozycki
2024-07-15 14:08     ` Jan Beulich
2024-07-12 13:07 ` [PATCH v2 12/17] TilePro: correct macro use in gas testsuite Jan Beulich
2024-07-12 13:07 ` [PATCH v2 13/17] Arm: relax gas testsuite whitespace expectations Jan Beulich
2024-07-12 13:10 ` [PATCH v2 14/17] aarch64: " Jan Beulich
2024-07-12 13:11 ` [PATCH v2 15/17] MIPS: " Jan Beulich
2024-07-15 12:12   ` Maciej W. Rozycki
2024-07-15 14:22     ` Jan Beulich
2024-07-17  0:09       ` Maciej W. Rozycki
2024-07-17 10:40         ` Jan Beulich
2024-07-30 23:58           ` Maciej W. Rozycki
2024-07-31 10:14             ` Jan Beulich
2024-07-12 13:12 ` [PATCH v2 16/17] Sparc: " Jan Beulich
2024-07-15 14:17   ` Jose E. Marchesi
2024-07-12 13:18 ` [PATCH v2 17/17] gas: have scrubber retain more whitespace Jan Beulich
2024-07-14 14:29 ` [PATCH v2 00/17] gas: scrubber adjustments Alan Modra
2024-07-17  0:13 ` Maciej W. Rozycki
2024-07-21 20:15   ` VAX test coverage (was: [PATCH v2 00/17] gas: scrubber adjustments) Jan-Benedict Glaw
2024-07-19 13:22 ` [PATCH v2.5 01.5/17] x86: accept whitespace around prefix separator Jan Beulich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).