[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gcc compiler bug (sparc, ppc)



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

Note that even though this kind of list operation is frequent, the
pathological case that would suffer from the bug is certainly
not.

T.
> Ralf
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>