gcc optimization return value handling

[Andrew Haley]

rekisum@web.de wrote:

> I already put this in the FreeRTOS forum with no result so far:
> 
> I got hit by a very strange GCC/FreeRTOS problem. 
> In a task I check the return value of a function like this: 
>  
> int ret; 
>  
> if( xQueueReceive(QueueMain, &Event, portMAX_DELAY) == pdTRUE ) 
> {
>    switch(Event.id) 
>    { 
>       case EV_KEY_MENU_OK: 
>       ret = menu_descend(); 
>       if( ret != 0 ) 
>       { . . . . . 
> .
> .
> .
>  
> Using this code the system hangs after returning from menu_descend()! 
> The program gets stuck in xQueueReceive() in an endless loop of xTaskResumeAll(). 
> There is a while loop: 
> while( ( pxTCB = ( tskTCB * ) listGET_OWNER_OF_HEAD_ENTRY( ( ( xList * ) &xPendingReadyList ) ) ) != NULL ) 
>  
> As there is an portENTER_CRITICAL() in the beginning of that routine there 
> interrupts are disabled, the os tick is no longer called. 

Where is this while loop?  What has it to do with the the code above?

> But, when I declare ret as volatile 
> volatile int ret; 
> the program runs as expected! 
>  
> Looking at the assembler code shows: 
> Without volatile: 
>  
> bl menu_descend 
> cmp r0, #0 
> beq .L123 
>  
> With volatile: 
>  
> bl menu_descend 
> str r0, [sp, #84] 
> ldr r3, [sp, #84] 
> cmp r3, #0 
> beq .L123 
>  
> So it looks like that storing the return value on the stack 
> and using r3 for comparison against zero saves my program 
> from getting stuck. 
>  
> From here I only can guess. 
> Maybe gcc tricks itself by the assumption that there lies a return value 
> of the function on stack, but optimisation uses r0 for handover directly instead,  
> and from there on the stack pointer is one position to low? 

That seems unlikely.  In both of these the return value is in r0.

> Or has it to do with register treatment of freertos, especially register r0? 
>  
> I use freertos version 3.2 ( because thats what the project started with 
> and I'm not allowed to upgrade ;-) 
> It's a port for the STR7 ARM7 from ST. 
> gcc is arm-elf-gcc 4.2.2 
> optimization level is 2 
>  
> All that really frightens me! 
> I must use optimization, at least for size, as the code got to big. 
>  
> What goes wrong here? 

We don't know, because there's not really enough information.  The example code
you provided looks fine, both with and without volatile.

Andrew.