gcc compiler bug (sparc, ppc)

[Ralf Corsepius]

On Wed, 2007-05-23 at 08:43 -0700, Till Straumann wrote:
> Ralf Corsepius wrote:
> > On Wed, 2007-05-23 at 08:07 -0500, Joel Sherrill wrote:
> >   
> >> Ralf Corsepius wrote:
> >>     
> >>> 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.
> >>>   
> >>>       
> >> Not in the general sense but this looks remarkably like the RTEMS chain code
> >> and the intent there was very simple.  The code was originally in assembly
> >> language and we really meant each memory load or store to occur. 
> >>     
> > This code above is a standard "list-type" operation and is not related to volatiles at all.
> >
> > Given the fact such constructs are very common, I strongly doubt Till to
> > be first to trip them, so there is likely either something we are
> > missing or a bug in GCC.
> >   
> I did search the gcc bug database but didn't find anything
> (needle in haystack problem).
I meanwhile tried the same, ... same result ...

>  Also, the fact that the problem
> has been there for a while (at least 3.2.3 ... 4.1.1) makes me
> believe that it might not have been reported yet.
This is what baffles me - such constructs are such kind of common, my
gut feeling is, "we must be missing something".

BSD queues (sys/queue.h) are based on similar working principles, c++
lists etc. also are ... so what is the trick they apply/what are we
missing?

> Note that even though this kind of list operation is frequent, the
> pathological case that would suffer from the bug is certainly
> not.
Are you able to write a piece of application-code to visibly expose the
effect? I've tried to do so but, no success so far.

Ralf