This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Change to readonly conflict handling
- To: kenner at vlsi1 dot ultra dot nyu dot edu
- Subject: Re: Change to readonly conflict handling
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Sun, 17 Sep 2000 17:13:14 -0700
- CC: gcc-patches at gcc dot gnu dot org
- References: <10009172306.AA12001@vlsi1.ultra.nyu.edu>
> Date: Sun, 17 Sep 00 19:06:02 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> Cc: gcc-patches@gcc.gnu.org
> Here's something similar in C, though it generates a warning:
>
> struct foo {const int a; int b;};
>
> void
> sub1 (struct foo *p, struct foo *q)
> {
> *p = (struct foo) {1, 2};
> *q = *p;
> }
>
> If you look at the RTL, you'll see that one word of *p is being stored with /u
> and loaded without it. (They also have different alias sets, but that's
> probably something I did in my last change and will fix momentarily.)
This code is actually not valid C; neither of the two assignments are
valid, because they change p->a and q->a which are 'const'. Thus the
invalid RTL. (The first expression is not a constructor, it's an
assignment from a temporary.)
Actually, what I get is _both_ words of *p and *q being stored with
/u. On powerpc (so the fields are SImode):
(insn 4 2 6 (set (reg/v:SI 82)
(reg:SI 3 r3)) -1 (nil)
(nil))
(insn 6 4 7 (set (reg/v:SI 83)
(reg:SI 4 r4)) -1 (nil)
(nil))
(note 7 6 12 NOTE_INSN_FUNCTION_BEG -1347440721)
(insn 12 7 13 (set (reg:SI 85)
(high:SI (symbol_ref:SI ("*.LC0")))) -1 (nil)
(nil))
(insn 13 12 15 (set (reg:SI 84)
(lo_sum:SI (reg:SI 85)
(symbol_ref:SI ("*.LC0")))) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:SI ("*.LC0"))
(nil)))
(insn 15 13 16 (set (reg:DI 86)
(mem/s:DI (reg:SI 84) 0)) -1 (nil)
(nil))
(insn 16 15 19 (set (mem/s/u:DI (reg/v:SI 82) 0)
(reg:DI 86)) -1 (nil)
(nil))
(insn 19 16 20 (set (reg:DI 87)
(mem/s:DI (reg/v:SI 82) 0)) -1 (nil)
(nil))
(insn 20 19 22 (set (mem/s/u:DI (reg/v:SI 83) 0)
(reg:DI 87)) -1 (nil)
(nil))
(note 22 20 24 NOTE_INSN_FUNCTION_END -1347440721)
I'm thinking this may be the bug you're looking for.
I couldn't convince gcc to actually generate a reference to one field
with /u and to the other field without. Will it really do that?
--
- Geoffrey Keating <geoffk@cygnus.com>