conversion of the __inline__ and inline pragmas to RTEMS_INLINE_ROUTINE?

Ralf Corsepius ralf.corsepius at
Wed Nov 9 15:40:35 UTC 2011

On 11/09/2011 03:42 PM, Joel Sherrill wrote:
> On 11/09/2011 08:20 AM, Gedare Bloom wrote:
>> On Wed, Nov 9, 2011 at 3:55 AM, Ralf 
>> Corsepius<ralf.corsepius at>  wrote:
>>> On 11/09/2011 09:49 AM, Sebastian Huber wrote:
>>>> Hi,
>>>> On 11/04/2011 09:15 PM, Cudmore, Alan P. (GSFC-5820) wrote:
>>>>> Hi,
>>>>> Is there an effort to convert the __inline__ and inline compiler
>>>>> pragmas into the RTEMS_INLINE_ROUTINE macro?
>>>>> I noticed that there is still a mixture of __inline__, inline, and
>>>>> RTEMS_INLINE_ROUTINE in 4.10.1.
>>>> I would replace all __inline__ and RTEMS_INLINE_ROUTINE with 
>>>> inline. ISO
>>>> C 99 is now 12 years old.
>>> I would replace all inline and RTEMS_INLINE_ROUTINE with __inline__ 
>>> because
>>> the rtems toolchain is _far_ from being c99 compliant.
>> It sounds like Alan's requirements are to not use __inline__, unless I
>> misunderstood. So every inline should be RTEMS_INLINE_ROUTINE so that
>> inlining is a switch that can be turned off.
> We are not always going to be tied to gcc so anything that makes
> it harder to port to a non-GNU compilers is not a good thing.  Leaving
> macros like RTEMS_INLINE_ROUTINE in place was done to allow
> use of different compilers.  When added, we could still be compiled
> with non-GNU compilers.
Well, the sad and unpleasant truth is: RTEMS is closer tied to GCC than 
it ever was. Telling people it was possible to compile RTEMS with 
non-gcc's is cheating to yourselves.

> We already have bsp_specs which need to go away.  They
> are strictly gcc-isms and non-standard.
Right, ...

> I am in the experimentation and investigation stage of compiling
> RTEMS with non-gcc compilers. Please do not tie us to gcc
> any tighter than we already are.
The reasons for keeping then is: To be able to test for c99 and POSIX 
compliance you need to be able to compile RTEMS with CFLAGS which are 
violently enforcing "non-c99/non-POSIX" c-dialects - I occasionally do 
so and am trying to improve things.

Once this will have reached a sufficient status (IMO, we are in less 
problematic shape than we were some years ago), we can switch all at 
once to "c99".

Unfortunately, esp. newlib is not in a shape, which renders such efforts 
an easy task nor is RTEMS excessive usage of defines helpful.


More information about the users mailing list