conversion of the __inline__ and inline pragmas to RTEMS_INLINE_ROUTINE?

[Joel Sherrill]

On 11/9/2011 9:40 AM, Ralf Corsepius wrote:
> 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 rtems.org>   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.
And that needs to be addressed.  The only way to do that is to attempt 
to compile
with non-gcc compilers.  I have made progress with clang and can compile up
until the build process hits bsp_specs.  That is the next hurdle to clear.

After that, I plan to do a "empty" port to some target with another FOSS 
compiler like
OpenWatcom, sdcc, or pcc.  It doesn't have to run at first -- just flag 
gcc-isms.

Your focus is on the gcc-isms in the source code.  The code at one point 
did
compile with the Metrowerks and GreenHills compilers.  It has been a 
long time
but it did work at one point.

I worry that the build system has more dependencies on gcc.
>> We already have bsp_specs which need to go away.  They
>> are strictly gcc-isms and non-standard.
> Right, ...
And if we accept that as something that can't be changed, it will never 
change.

I want to be able compile RTEMS with non-GNU toolsets.  That is a goal.  It
does not have a deadline or say it is easy.  It is a series of steps and 
challenges.

The first step was getting RTEMS to compile at all with clang (x86 target).
The next step is to link and run a program with clang.

The next hurdle is bsp_specs.
>> 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.
That's fine.  We have not set the minimum requirements for a non-GNU 
compiler.
> 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.
Then submit patches to them.  They want to improve as well.
> Ralf
>