Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Wolfram Wadepohl]

Till Straumann schrieb:

> I agree with Linus' sentiment, too. The problem, however,
> is (repeating mantra) that this is not just some weirdo
> gcc optimization that can be switched off. It is the C99 *standard*.
> Even if you can switch this off for gcc today, there is no
> guarantee that you will be able to in the future or on other
> compilers. If we want to produce C99 compliant code then
> we must comply with the alias rule. period.

> Steven Johnson wrote:
>>I have been quietly following this thread, but I find the whole 
>>-fstrict-aliasing/-fnostrict-aliasing issue to be very disturbing.  
>>Luckily my program isn't built with -O2 or I probably would have been 
>>tracking untold numbers of strange bugs in known working code.  For 
>>the C language to change so that a pointer (regardless of the pointer 
>>type used to reference that memory) no longer points to a known piece 
>>of memory, in a predictable way is whacked.
>>
>>I for one do not look forward to adding __attribute__ ((may_alias)) to 
>>the hundreds of places where I change the way I address memory using 
>>pointers.  It is a monumental waste of time, prone to error and in my 
>>opinion putting in declarations to fix a broken compiler 
>>optimisation.  When a compiler optimisation breaks a fundamental 
>>aspect of C that has existed since the beginnings of the language, 
>>then I consider that optimisation to be broken, and not the code 
>>itself.  I will be adding -fno-strict-aliasing to all of my builds in 
>>future, and I will be making sure RTEMS (and all of the other Open 
>>Source libraries I use) builds with -fno-strict-aliasing, regardless 
>>of what is ultimately decided here),  I just don't want the headache.  
>>In my opinion you wouldn't be fixing RTEMS by adding these 
>>declarations or changing the code, you would be working around a 
>>broken compiler.  The other OS's that use -fno-strict-aliasing are (in 
>>my opinion) doing the right thing.  I also fail to see how the option 
>>could yield any tangible benefits on performance that would warrant 
>>the pain and difficulty it causes.
>>
>>But that is my 2c.

Hi all,

i've follwed the discussion on the list. As a user of RTEMS building 
comercial *embedded* applications with high availability the only short 
term solution is to use -fno-strict-aliasing for the whole program 
including all RTEMS parts.

Till is right in telling us the gcc optimization (weird or not) *is* C99 
standard. Following this argumentation and expecting that 
-fno-strict-aliasing will be dropped eventually and also considering that 
we write embedded code dealing with real hardware i ask the question if C 
is the right language to implement these applications in the future. A 
programming language forcing me to consider what machine code the compiler 
will eventually produce is not worth using for *embedded* programming.

In general and from an academic point of view Ralf is totally right; the 
standard is clear and the code should be fixed. A proper data model, well 
designed from base on,  will hopefully not produce aliasing problems. But 
is this always possible and adequate in real work? It shuold be for basic 
technology like RTOS or general libraries like newlib!

In fact the current RTEMS code is not in the shape that aliasing is not 
considered as a problem. It has grown over more than a decade of years.
Is this the time for a complete rewrite? Can we fix it? What piece of work 
can i do, as a user with limited knowledge of kernel functonality?

-- 
Schöne Grüße aus Reutlingen

Wolfram Wadepohl
Forschung & Entwicklung

E&K AUTOMATION
Indumat GmbH & Co. KG
Siemensstraße 3
72766 Reutlingen
Deutschland

Tel.  +49 7121 514-289
Fax   +49 7121 514-299
eMail W.Wadepohl at indumat.de
       Wolfram.Wadepohl at ek-automation.com
       W.Wadepohl at ieee.org
WWW   http://www.indumat.de
       http://www.ek-automation.com


Bitte senden Sie mir keine Word- oder PowerPoint- (tm Microsoft) Anhänge.
Senden Sie mir einfachen Text, HTML oder PDF.
Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3189 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.rtems.org/pipermail/users/attachments/20061207/a15f93dc/attachment.bin>