AVR-GCC for Linux doesn't handle well 16 bit words

Here’s something to gag on…

Stack Overflow

Your shift "bug" is not a bug at all! The compile is doing PRECISELY what the c/c++ language specification specifies it should do. Your code is the problem, and I could see it the instant I looked at your code.

Rule #1: If you think you've found a compiler bug, you haven't. That goes DOUBLE if the "bug" is in some fundamental capability, like arithmetic. Such a bug could NEVER survive the tortuous regression tests that all gnu compiler releases much go through before release.

Back to the original problem in post #1 which still does not appear to have been solved. That is that a while loop appears, under certain circumstances, not to have executed when it should have.

I have made the following observation based on the output shown in post #1 and post #11 :

In the “failure” case, the number of ticks which elapse between the “before” and “after” time stamps is random and usually greater than one. In two cases, it is as much as 9 ticks.
In the “success” case the difference between the adjacent time stamps is 1 tick.

This would indicate that, in the failure case, the while loop is in fact executing, and a number of times, before prematurely failing. This supports the “non atomic read” theory in post #32.

The test is simpler than previously suggested although not necessarily a solution. Simply wrap the asynchronously updateable part in cli()/sei() as below. If that appears then to perform correctly, it would show that the attempt in xTaskGetTickCount() to handle multiple byte variables atomically has failed.

From post #1 :

void software_delay( TickType_t ticks )
   volatile TickType_t now = xTaskGetTickCount();

   Serial.print( "\nBefore: " ); Serial.println( now );

   volatile TickType_t next_wakeup = now + ticks;
   Serial.print( "Next: " ); Serial.println( next_wakeup );

   while( 1 )
      if( now > next_wakeup ) 
      cli() ; // suspect the following is non atomic 
      now = xTaskGetTickCount();
      sei() ;

   Serial.print( "After: " ); Serial.println( now );

If that is not compatible with the RTOS such that the above test cannot be carried out then, in the while loop, do a test to see if the value of the variable “now” is, at any time, less than its immediately previous value (as may be the case in a partial read operation) and, if so, print an error message.

I'd expect that a RTOS does not allow tasks to block interrupts. Instead the macros for critical sections or atomic reads should be used.

Sure it does. Certainly on an AVR there is no way to prevent it from doing so.

This was intended as a test only but I did also consider the very remote possibility that it could somehow inhibit the return of a result, hence my caution. cli() / sei() anyway in a tight loop may not be such a good idea.

Incidentally, I did notice afterwards that there is an even better example to show that the while() loop got even further. From post #1:

Here it appeared to run for 42 ticks (I believe milliseconds). I wonder if some actually worked if he specified a small enough delay interval.

Of course a framework can define the functions cli() and sei() as appropriate. Same for Arduino interrupts() and noInterrupts().

From the problems of the OP I also could imagine that RTOS has problems with 8 bit controllers, not the compiler.

All in all: could anybody reproduce the errors using the Arduino framework and compiler?