gcc compiler bug (sparc, ppc)

[Ralf Corsepius]

On Wed, 2007-05-23 at 06:30 -0500, Joel Sherrill wrote:
> Sergei Organov wrote:
> > Till Straumann <strauman at slac.stanford.edu> writes:
> >   
> >> I found that gcc produces bad code for the
> >> following example:
> >>
> >> struct node {
> >>      struct node *next, *prev;
> >> };
> >>
> >> void xtract(struct node *x)
> >> {
> >> struct node *n, *p;
> >>     n = x->n;
> >>     p = x->p;
> >>     n->prev = p;
> >>     p->next = n;
> >> }
> >>     
> >
> > This doesn't compile:
> >
> > np.c: In function ‘xtract’:
> > np.c:8: error: ‘struct node’ has no member named ‘n’
> > np.c:9: error: ‘struct node’ has no member named ‘p’
> >
> > I think you mean:
> >
> > void xtract(struct node *x)
> > {
> >     struct node *n, *p;
> >     n = x->next;
> >     p = x->prev;
> >     n->prev = p;
> >     p->next = n;
> > }
> >
> > right?
> >
> >   
> Changing the structure definition to make the pointers volatile appears
> to result in correct code.
IMO, this is bad advice, these ain't no volatiles.

Till, please ask on gcc@

> >> powerpc-rtems-gcc -O -fschedule-insns -fno-strict-aliasing
> >> (version 4.1.1) produces:
> >>     
> > [...]
> >   
> >> The order of the last two assignments was swapped
> >> which makes a difference in the special case where &p->next and
> >> &n->prev are addressing the same location but n != p.
> >>     
> >
> > You mean when *n and *p overlap like this?:
> >
> >   n ->  |next|prev|
> >   p ->       |next|prev|
> >
> >   
> >> The bug is apparently triggered by -fschedule-insns; if I turn
> >> on all other optimizations (including -fstrict-aliasing) correct
> >> code is generated.
> >>     
> >
> > -fstrict-aliasing should have no effect here, I think, as all the
> > pointers involved have the same type and are therefore allowed to alias
> > each other anyway.
> >
> > PPC GCC 2.95.2 seems to produce correct code using
> >
> > powerpc-rtems-gcc -O -fschedule-insns -fno-strict-aliasing:
> >
> > xtract:
> > 	lwz %r11,0(%r3) # r11 = n = x->next
> > 	lwz %r9,4(%r3)  # r9  = p = x->prev
> > 	stw %r9,4(%r11) # n->prev = p
> > 	stw %r11,0(%r9) # p->next = n
> > 	blr
> >
> >
> > Overall, it looks like gcc bug indeed. Did you file bug-report?
> >
> > -- Sergei.
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >   
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users