Hello All.
We have been working with FreeRtos and WinAVR from 2005 until we needed to port the system on Atmega644 chip. It required new library and we had to migrate to WinAVR 20070525. Now it compiles the system with warnings. Optimization level is '0'. Could anybody advice what shall we change it code to reach 'clean' compilation?
Regards
Alex.

What are the warnings?

Regards.

---------- Capture Output ----------
These began occurring after updating WinAVR.

We get these messages when compiling with optimization = s.
Compiling with optimization = 0, cleans up much of these warnings but the result crashes during initialization.

Compiling: /newFreeRTOS/FreeRTOS/Source/tasks.c
/newFreeRTOS/FreeRTOS/Source/tasks.c:

In function 'vTaskSwitchContext':
/newFreeRTOS/FreeRTOS/Source/tasks.c:1455: warning: dereferencing type-punned pointer will break strict-aliasing rules

/newFreeRTOS/FreeRTOS/Source/tasks.c:

In function 'prvListTaskWithinSingleList':
/newFreeRTOS/FreeRTOS/Source/tasks.c:1841: warning: dereferencing type-punned pointer will break strict-aliasing rules
/newFreeRTOS/FreeRTOS/Source/tasks.c:1844: warning: dereferencing type-punned pointer will break strict-aliasing rules
/newFreeRTOS/FreeRTOS/Source/tasks.c: In function 'xTaskResumeAll':
/newFreeRTOS/FreeRTOS/Source/tasks.c:1331: warning:

inlining failed in call to 'vTaskIncrementTick': --param max-inline-insns-single limit reached
/newFreeRTOS/FreeRTOS/Source/tasks.c:1171: warning: called from here

Compiling: /newFreeRTOS/FreeRTOS/Source/queue.c
avr-gcc -c -mmcu=atmega128 -I. -g -DF_CPU=16000000UL -DID=50 -Dadc -DINTG=8 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Winline -Wa,-adhlns=/newFreeRTOS/FreeRTOS/Source/queue.lst -std=gnu99 -MD -MP -MF .dep/queue.o.d /newFreeRTOS/FreeRTOS/Source/queue.c -o /newFreeRTOS/FreeRTOS/Source/queue.o

Compiling: /newFreeRTOS/FreeRTOS/Source/list.c
avr-gcc -c -mmcu=atmega128 -I. -g -DF_CPU=16000000UL -DID=50 -Dadc -DINTG=8 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Winline -Wa,-adhlns=/newFreeRTOS/FreeRTOS/Source/list.lst -std=gnu99 -MD -MP -MF .dep/list.o.d /newFreeRTOS/FreeRTOS/Source/list.c -o /newFreeRTOS/FreeRTOS/Source/list.o
/newFreeRTOS/FreeRTOS/Source/list.c: In function 'vListInitialise':
/newFreeRTOS/FreeRTOS/Source/list.c:97: warning: dereferencing type-punned pointer will break strict-aliasing rules
/newFreeRTOS/FreeRTOS/Source/list.c:105: warning: dereferencing type-punned pointer will break strict-aliasing rules
/newFreeRTOS/FreeRTOS/Source/list.c:106: warning: dereferencing type-punned pointer will break strict-aliasing rules
/newFreeRTOS/FreeRTOS/Source/list.c: In function 'vListInsert':
/newFreeRTOS/FreeRTOS/Source/list.c:163: warning: dereferencing type-punned pointer will break strict-aliasing rules

Linking: pls_50_adc.elf
avr-gcc -mmcu=atmega128 -I. -g -DF_CPU=16000000UL -DID=50 -Dadc -DINTG=8 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Winline -Wa,-adhlns=pulse1.o -std=gnu99 -MD -MP -MF .dep/pls_50_adc.elf.d pulse1.o TimeControl.o i2control.o PM.o ADC.o settings.o Uart0.o Uart1.o check.o commandLine.o Fram.o onewire.o database.o /newFreeRTOS/FreeRTOS/Source/tasks.o /newFreeRTOS/FreeRTOS/Source/queue.o /newFreeRTOS/FreeRTOS/Source/list.o /newFreeRTOS/freeRTOS/Source/portable/GCC/ATMega323/port.o /newFreeRTOS/freeRTOS/Source/portable/MemMang/heap_1.o /project/avrlib/avrlib/rprintf.o --output pls_50_adc.elf -Wl,-Map=pls_50_adc.map,--cref -Wl,-u,vfprintf -lprintf_min -lm

Creating load file for Flash: pls_50_adc.hex
avr-objcopy -O ihex -R .eeprom pls_50_adc.elf pls_50_adc.hex

Creating load file for EEPROM: pls_50_adc.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex pls_50_adc.elf pls_50_adc.eep
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be copied!
c:\WinAVR-20070525\bin\avr-objcopy.exe: --change-section-lma .eeprom=0x00000000 never used
C:\WinAVR\utils\bin\make.exe: [pls_50_adc.eep] Error 1 (ignored)

Creating Extended Listing: pls_50_adc.lss
avr-objdump -h -S pls_50_adc.elf > pls_50_adc.lss

Creating Symbol Table: pls_50_adc.sym
avr-nm -n pls_50_adc.elf > pls_50_adc.sym

Converting to AVR Extended COFF: pls_50_adc.cof
avr-objcopy --debugging --change-section-address .data-0x800000 --change-section-address .bss-0x800000 --change-section-address .noinit-0x800000 --change-section-address .eeprom-0x810000 -O coff-ext-avr pls_50_adc.elf pls_50_adc.cof
Warning: file C:/WINDOWS/TEMP/ccv0xIWh.s not found in symbol table, ignoring
Warning: ignoring function __vectors() outside any compilation unit
Warning: ignoring function __bad_interrupt() outside any compilation unit
avr-objcopy: --change-section-vma .eeprom+0xff7f0000 never used
avr-objcopy: --change-section-lma .eeprom+0xff7f0000 never used
avr-objcopy: --change-section-vma .noinit+0xff800000 never used
avr-objcopy: --change-section-lma .noinit+0xff800000 never used

Size after:
pls_50_adc.elf :
section size addr
.data 484 8388864
.text 69618 0
.bss 2543 8389348
.stab 1044 0
.stabstr 113 0
.debug_aranges 564 0
.debug_pubnames 5737 0
.debug_info 52822 0
.debug_abbrev 8058 0
.debug_line 38683 0
.debug_frame 3472 0
.debug_str 9304 0
.debug_loc 10857 0
.debug_ranges 36 0
Total 203335


AVR Memory Usage:
-----------------
Device: atmega128

Program: 70102 bytes (53.5% Full)
(.text + .data + .bootloader)

Data: 3027 bytes (73.9% Full)
(.data + .bss + .noinit)


-------- end --------


> Terminated with exit code 0.

Yes, I see the same warnings:
warning: dereferencing type-punned pointer will break strict-aliasing rules

A few of these popped up when compiling tasks.c for example, this line produced the type-punned pointer warning.
listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );

I only see the warning if compiled with full optimization -Os. There are no warnings if compiled with -O0. I have no idea what a type-punned pointer is.

This is something that came up in AVR and ARM at a particular compiler version. I don't think it is an issue, but please let me know if this is not the case.

In the example you give, I think it is generated by the following line within the listGET_OWNER_OF_NEXT_ENTRY macro:

if( ( pxConstList )->pxIndex == ( xListItem * ) &( ( pxConstList )->xListEnd ) )

as xListEnd is of type xMiniListItem rather than xListItem. This is done to save RAM on small 8 and 16 biters. You could change the type to xListItem, or change the compilation options to get rid of the warning.

-Wstrict-aliasing (generate the warning) is included in -Wall.

-fstrict-aliasing
Allows the compiler to assume the strictest aliasing rules applicable to the language
being compiled. For C (and C++), this activates optimizations based on the type of
expressions. In particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are almost the same.
For example, an "unsigned int" can alias an "int", but not a "void*" or a "double". A
character type may alias any other type.

Pay special attention to code like this:

union a_union {
int i;
double d;
};

int f() {
a_union t;
t.d = 3.0;
return t.i;
}

The practice of reading from a different union member than the one most recently writ­
ten to (called ``type-punning'') is common. Even with -fstrict-aliasing, type-punning
is allowed, provided the memory is accessed through the union type. So, the code
above will work as expected. However, this code might not:

int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}

Every language that wishes to perform language-specific alias analysis should define a
function that computes, given an "tree" node, an alias set for the node. Nodes in
different alias sets are not allowed to alias. For an example, see the C front-end
function "c_get_alias_set".

Enabled at levels -O2, -O3, -Os.


Regards.

Richard,

You have in your change log that you fixed the WinAVR errors in the latest version. Can you list what changes needed? Im a little scared moving to v5 of the RTOS. I hade a look through some of the source and couldnt really see what was changed.

If its to involved dont worry, I will just keep ignoring the warnings... I just normally like to have errors on my warnings.

PS. Im tlaking about the aliasing warnings.

Cheers

Murray

The warnings I was referring to were generated by the use of the inline keyword. The latest FreeRTOS.org release has removed the use of the keyword altogether.

If the aliasing warnings you are referring to are generated for the lines that use the "mini" list structure in place of the full list structure then you can ignore the warnings quite safely, or simply turn that warning off in the makefile.

Regards.