This is the mail archive of the
mailing list for the GCC project.
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)
asm ("" : "=m" (p));
p = 7;
p = 17;
RTL at sched2 time contains:
(insn:TI 19 24 21 2 PX.c:5 (set (mem/s:BLK (reg:DI 11 11 ) [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