This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/25008] New: problems with "S" constraint in asms


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.


-- 
           Summary: problems with "S" constraint in asms
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25008


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]