public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/45274]  New: __restrict__ type qualifier does not work on pointers to bitfields
@ 2010-08-13  7:06 anton at samba dot org
  2010-08-13  8:01 ` [Bug middle-end/45274] " jakub at gcc dot gnu dot org
  0 siblings, 1 reply; 2+ messages in thread
From: anton at samba dot org @ 2010-08-13  7:06 UTC (permalink / raw)
  To: gcc-bugs

I tested an svn build from 20100813 with the following code:

struct bar {
        unsigned int a:1, b:1, c:1, d:1, e:28;
};

void foo(struct bar * __restrict__ src, struct bar * __restrict__ dst)
{
        dst->a = src->a;
        dst->b = src->b;
        dst->c = src->c;
        dst->d = src->d;
        dst->e = src->e;
}

Built as 32bit, we see loads and stores as if the compiler is following pointer
aliasing rules:

# gcc -m32 -O2 -S foo.c 

foo:
        lwz 9,0(3)
        lwz 0,0(4)
        rlwimi 0,9,0,0,0
        stw 0,0(4)
        lwz 9,0(3)
        rlwimi 0,9,0,1,1
        stw 0,0(4)
        lwz 9,0(3)
        rlwimi 0,9,0,2,2
        stw 0,0(4)
        lwz 9,0(3)
        rlwimi 0,9,0,3,3
        stw 0,0(4)
        lwz 9,0(3)
        rlwimi 0,9,0,4,31
        stw 0,0(4)
        blr

Apologies if I am misusing or misinterpreting the use of __restrict__ here.

Also, when built as 64bit things are considerably more complex. Is there a
reason why we can't use the same code as 32bit?

# gcc -m64 -O2 -S foo.c
...
.L.foo:
        lwz 9,0(4)
        lwz 0,0(3)
        rlwinm 9,9,0,1,31
        rlwinm 0,0,0,0,0
        or 0,9,0
        stw 0,0(4)
        rlwinm 0,0,1,1,31
        rlwinm 0,0,31,0xffffffff
        lwz 9,0(3)
        rldicl 9,9,34,63
        slwi 9,9,30
        or 0,0,9
        stw 0,0(4)
        rlwinm 9,0,2,1,31
        rlwinm 9,9,30,0xffffffff
        lwz 0,0(3)
        rldicl 0,0,35,63
        slwi 0,0,29
        or 0,9,0
        stw 0,0(4)
        rlwinm 0,0,3,1,31
        rlwinm 0,0,29,0xffffffff
        lwz 9,0(3)
        rldicl 9,9,36,63
        slwi 9,9,28
        or 0,0,9
        stw 0,0(4)
        rlwinm 0,0,0,0,3
        lwz 9,0(3)
        rlwinm 9,9,0,4,31
        or 0,0,9
        stw 0,0(4)
        blr


-- 
           Summary: __restrict__ type qualifier does not work on pointers to
                    bitfields
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-unknown-linux-gnu


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug middle-end/45274] __restrict__ type qualifier does not work on pointers to bitfields
  2010-08-13  7:06 [Bug middle-end/45274] New: __restrict__ type qualifier does not work on pointers to bitfields anton at samba dot org
@ 2010-08-13  8:01 ` jakub at gcc dot gnu dot org
  0 siblings, 0 replies; 2+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-08-13  8:01 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from jakub at gcc dot gnu dot org  2010-08-13 08:01 -------
I don't think this has anything to do with restrict and all with lowering
bitfield accesses only during expansion, and at RTL level the bitfield
operations being too big for combiner to optimize them.


-- 


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-08-13  8:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-13  7:06 [Bug middle-end/45274] New: __restrict__ type qualifier does not work on pointers to bitfields anton at samba dot org
2010-08-13  8:01 ` [Bug middle-end/45274] " jakub at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).