gettimeofday seconds rollover problem?

[Joel Sherrill]

Eric Norum wrote:

> On Feb 27, 2006, at 10:18 AM, Joel Sherrill wrote:
>
>>
>>
>> I liked the suggestion that the memory barriers be added to the ISR  
>> level wrappers not the
>> CPU specific implementations.
>
>
> Till has performance concerns about this.   I kind of agree that if  
> it is sufficient that only volatile variables are modified inside a  
> disabled section then there's no real need to add the barriers.
>
I agree.  If volatile is sufficient, then I don't want to do anything 
else. 

>>
>> You noted that cc needed to be added to the m68k which has to be  CPU 
>> dependent.
>
>
> I'm not sure that this is really necessary.  I don't think that the  
> compiler can really assume anything about the condition codes anyway.
>
Then let's ignore this one for now.

>>
>>> 3) Are the "memory" barriers going to be added to the   
>>> _Thread_Dispatch_disable/enable macros?     If so, by whom and why  
>>> do  the arguments against adding the barriers to the interrupt  
>>> macros not  apply here as well?
>>>
>> I think the memory barriers need to be added to those macros given  
>> the argument.  We don't want something
>> moved outside any critical section so we need to draw our own  
>> Maginot Line.  I hope ours works well though. :)
>
>
> The "if it is sufficient that only volatile variables are modified  
> inside a disabled section then there's no real need to add the  
> barriers" argument applies here, too.  Of course that assumes that we  
> figure out the exhaustive list of variables that need to be declared  
> volatile.  I think that Joel had a good start on this list.
>
Can those who have been looking at the generated code try volatile on 
the list of variables I proposed?

If that's enough, it is a pretty mild patch.

--joel