gcc compiler bug (sparc, ppc)

[Sergei Organov]

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?

> 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.