GCC Bugzilla Bug 25008

The following testcase compiles with gcc-4.0, but generates an error with
optimization with gcc-4.1.

int *
sub (int *i, int k)
{
  int j;
  for (j = 0; j < 16; j++)
    {
      asm volatile ("foo %0" : "=S" (*i));
      i += k;
    }
  return i;
}

aretha$ ./xgcc -B./ -O2 -S -da tmp.c
tmp.c: In function ‘sub’:
tmp.c:7: error: ‘asm’ operand requires impossible reload

This was broken by my patch that defined EXTRA_MEMORY_CONSTRAINT.
    http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00714.html

I didn't have a testcase for that at the time, but now that I've run into
trouble, I went to the effort of creating of creating one.  It required adding
two letters, and deleting one.  The following testcase fails when compiled
without optimization with gcc-4.0.

int *
sub (int *i, int k)
{
  int j;
  for (j = 0; j < 16; j++)
    {
      asm volatile ("foo %0" : : "S" (*i));
      i += k;
    }
  return i;
}

aretha$ ./xgcc -B./ -S -da tmp2.c
tmp2.c: In function ‘sub’:
tmp2.c:7: error: impossible constraint in ‘asm’

The reason why defining EXTRA_MEMORY_CONSTRAINT fails for the first example is
because asm_operand_ok has code that says any memory operand is OK if
EXTRA_MEMORY_CONSTRAINT is true because it can be reloaded to fit.  This is
true in theory.  Unfortunately, reload doesn't know how to fix a MEM with a
POST_MODIFY address.  It fixes all MEMs that didn't quite match a MEM
constraint where an offsettable address is OK by reloading the address.
        else if (goal_alternative_matched[i] == -1
                 && goal_alternative_offmemok[i]
                 && MEM_P (recog_data.operand[i]))
          {
            operand_reloadnum[i]
              = push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,...
So if we have an operand (MEM (POST_MODIFY ...)) it is fixed by emitting an
insn (set (reg) (POST_MODIFY ...)) which fails to be recognized triggering the
error.  find_reloads_address knows how to fix this, but of course did not do
anything because this address is accepted by GO_IF_LEGITIMATE_ADDRESS.

The second example fails without EXTRA_MEMORY_CONSTRAINT defined because of
parse_input_constraint in stmt.c.  If EXTRA_CONSTRAINT_STR is not defined, then
it decides that no operand is acceptable.  When I posted the earlier patch, I
mentioned that it looked like we had a misplaced #endif, since the default here
should be to just accept all operands if we can't handle the constraint letter.

Unfortunately, taking a second look, I see that a parse_input_constraint change
doesn't work, because gimplify_asm_expr gives me the MEM operand I need only if
!allows_reg.

So it looks like I have to try to fix reload if I want this to work.

Confirmed.