This is the mail archive of the 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]

Re: [PATCH] Don't assume MEM_SIZE is always set in rs6000 adjacent_mem_locations (PR target/34225)

On Mon, Nov 26, 2007 at 09:20:46AM -0500, David Edelsohn wrote:
> 	There appear to be other issues involved.  This probably is not a
> complete fix.  Please do not approve patches like this.
> 	For instance, why shouldn't stack_tie has MEM attributes?  Why
> should stack_tie be considered an adjacent mem in this algorithm when it
> does not actually emit any real instructions?
> 	This patch probably just papers over the problem.  Please justify
> why it is correct.

It is easy to generate MEM_SIZE (mem) == NULL, try e.g.
extern void bar (char *p);
int foo (int n)
  char p[n];
  asm ("" : "=m" (p));
  p[0] = 7;
  p[26] = 17;
  bar (p);
  return 0;

RTL at sched2 time contains:

(insn:TI 19 24 21 2 PX.c:5 (set (mem/s:BLK (reg:DI 11 11 [131]) [2 A8])
        (asm_operands:BLK ("") ("=m") 0 []
             [] 578)) -1 (nil))

here MEM_SIZE is NULL, because MEM_SIZE must be either NULL, or
CONST_INT, and the size of *p is not constant.
I haven't tried hard to come up with a testcase where adjacent_mem_locations
would ICE on this, but this INSN 19 certainly satisfies the 
is_store_insn predicate which guards this.
So IMHO even if rs6000_emit_stack_tie is changed to give it some size (what
size would be meaningful?), assuming MEM_SIZE is always non-NULL on all MEMs
is wrong.


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