FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [August 2007 Threads] WinAVR 20070525 warningsPosted by baranov on August 27, 2007 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.
RE: WinAVR 20070525 warningsPosted by Richard on August 28, 2007 What are the warnings?
Regards.
RE: WinAVR 20070525 warningsPosted by HarryB on August 29, 2007 ---------- 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.
RE: WinAVR 20070525 warningsPosted by dcraw on December 10, 2007 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.
RE: WinAVR 20070525 warningsPosted by Richard on December 10, 2007 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.
RE: WinAVR 20070525 warningsPosted by Murray Hughes on July 9, 2008 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
RE: WinAVR 20070525 warningsPosted by Richard on July 9, 2008 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|