FreeRTOS Support Archive

The FreeRTOS support forum can be used for active support both from Amazon Web Services
and the community. In return for using our software for
free, we request you play fair and do your bit to help others! 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.

WinAVR 20070525 warnings

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?RegardsAlex.

RE: WinAVR 20070525 warnings

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.

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 warnings

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 warnings

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.