Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Joel Sherrill]

>   
>>  What piece of work 
>> can i do, as a user with limited knowledge of kernel functonality?
>>     
> Good question.
>
> ATM, from my point of view, people being familiar with certain flavors
> of asm who could identify aliasing showing effects on RTEMS code would
> be helpful. I have been trying to identify files being affected by
> strict-aliasing and meanwhile have a list consisting of ca. 20000 object
> (Note: *.o not *.c!) files (out of ca. 70000) from RTEMS-4.8, which are
> affected by aliasing.
>
> Now, identifying those which really are broken by aliasing would be
> necessary. So far, apart of Peer's/Thomas's case [1], I haven't found
> any :)
>   

I haven't seen your script but know a bit of your procedure so am going 
to propose
something.  I know you are diffing .s files but any differences as a 1st 
order check.
Is it possible to could load and store instructions in the two generated 
.s files and see
if the count differed?

for all files and multilib variants and (eventually) all BSPs
  (a) compile with and without strict aliasing
  (b) objdump .o and diff generated .s files
  if diff shows no changes
     OK.. strict aliasing did not change output, go on to the next file
  else
     count load and store instructions in both .s files
    if counts are same
       the file is 
OK                                                               # is 
this true?
    else
       definitely a HIGH candidate for breakage check by hand

I think the role of the user community is to help review the candidates 
Ralf's automated
procedure identifies and suggest ways to lower the number of false 
positives.  We can't
realistically check 20K files every time gcc bumps a version.

If no different in .s OR ld/st counts are sufficient to say strict 
aliasing had no bad impact,
then it is much easier to check the code automatically.

A similar technique could also be used to verify that soft-float/integer 
only executables
have no FPU instructions.

--joel