<div class="gmail_quote">On Fri, Aug 10, 2012 at 9:26 AM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 08/10/2012 03:59 AM, Sebastian Huber wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/09/2012 05:50 PM, Joel Sherrill wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry to keep pestering but we ended up with a deliberately unused<br>
parameter. Does that give a warning?<br>
</blockquote>
With the standard warning flags "-Wall -Wmissing-prototypes<br>
-Wimplicit-function-<u></u>declaration -Wstrict-prototypes -Wnested-externs" I get no<br>
error.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do we need to use the gcc pragma to note it is unused? I know in the<br>
test code, there is a conditional defined for this. It may have to move<br>
into the core like the memory barrier and other compiler specific macros<br>
</blockquote>
There are a lot of __attribute__((unused)) scattered around the code.<br>
<br>
We should think about using something similar to the FreeBSD cdefs.h file.<br>
They do a lot to cope with compiler dependencies, e.g.<br>
<br>
#if __GNUC_PREREQ__(2, 7)<br>
#define __dead2         __attribute__((__noreturn__))<br>
#define __pure2         __attribute__((__const__))<br>
#define __unused        __attribute__((__unused__))<br>
#define __used          __attribute__((__used__))<br>
#define __packed        __attribute__((__packed__))<br>
#define __aligned(x)    __attribute__((__aligned__(x))<u></u>)<br>
#define __section(x)    __attribute__((__section__(x))<u></u>)<br>
#endif<br>
<br>
This is a lot shorter than the RTEMS_ATTRIBUTE_XXX.<br>
<br>
</blockquote></div>
It is shorter. I question better because the BSD names already<br>
are duplicated in newlib. With the libbsd work, I have noticed<br>
that the conflicts/duplications for sys/cdefs.h are popping up<br>
again. If we use the same names a third time, this is just going<br>
to be worse.<br>
<br></blockquote><div>I would prefer something like this over inserting compiler builtins/attributes directly.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

If we can unify all this, it may be OK.  But sys/cdefs.h definitions<br>
have proven to be a thorn over the past years.<div class="im HOEnZb"><br>
<br>
-- <br>
Joel Sherrill, Ph.D.             Director of Research&   Development<br>
joel.sherrill@OARcorp.com        On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
    Support Available             <a href="tel:%28256%29%20722-9985" value="+12567229985" target="_blank">(256) 722-9985</a><br>
<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-devel</a><br>
</div></div></blockquote></div><br>