conversion of the __inline__ and inline pragmas to RTEMS_INLINE_ROUTINE?

[Ralf Corsepius]

On 11/09/2011 05:08 PM, Joel Sherrill wrote:
> 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.
Well, do you have clang's targetting rtems? The last time you mentioned 
clang, you were trying to compile RTEMS using linux-clangs.
Such attempts are of very doubtful wealth.

> After that, I plan to do a "empty" port to some target with another FOSS
> compiler like
> OpenWatcom, sdcc, or pcc.
Well, to me the key problem is to identify any other suitable FLOSS 
_cross_-compiler, which could be applied for testing. So far I am not 
aware of any.

I haven't heared about OpenWatcom before, but last time I had a look 
into sdcc, it was too primitive to be usable for RTEMS and pcc ... well, 
it's whole story of its own - Similar to clang, a version targetting 
linux can be found in Fedora :)

> Your focus is on the gcc-isms in the source code.
Correct.

> 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.
... must have been in the last millenium and long before my times in 
RTEMS :)

> I worry that the build system has more dependencies on gcc.
What do you have in mind?

>>> 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.
Actually, I hated them ever since they are around, but getting rid of 
them hard.

> The first step was getting RTEMS to compile at all with clang (x86 target).
You certainly have an x86-rtems port?

Compiling RTEMS with an x86-linux targetting clang is bogus and a waste 
of time.

>>> 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.
My perception is different. They are not interested in this level of 
compatiblity.

Ralf