linux-2.3.3 doesn't boot when compiled with egcs-2.93.22

[Franz Sirl]

Am Mon, 24 May 1999 schrieb Jeffrey A Law:
>In message < 19990524182719.A12059@fred.muc.de >you write:
>  > So I can never cast and modify the result with another >char type, assuming
>  > I want code that does not break with compilers that do inter module
>  > analyss?
>That is a good rule of thumb.  GCC does allow you to put them into a union
>and access them.  ie
>
>  union blah {
>      int x;
>      short y[2];
>  } x;
>  
>arf ()
>{
>  x.x = 0xdeadbeef;
>  hohum (x.y[1], x.y[0]);
>}
>
>
>Strictly speaking this is not valid according to ISO, but GCC allows it and
>will DTRT.

Hmm, how is your example related to this bugreport on egcs-bugs from
turly@apple.com:

Am Wed, 19 May 1999 schriebst Du:
>Hey there,
>
>There appears to be a problem with aliasing using egcs-1.1.1 PowerPC
>on an AIX box and egcs-1.1.2 on a MacOS X box.
>
>Compiling the following snippet with egcs-1.1.x -O2
>
>   unsigned long bad(int reg, unsigned long inWord)
>   {
>       union {
>           unsigned long word;
>           unsigned char byte[4];
>       } data;
>
>       data.word = inWord;
>       data.byte[reg] = 0;
>
>       return data.word;
>   }
>
>gives us:
>
>   stw  r4, -8(r1)    <--- data.word = inWord
>   addi r9, r1, -8    <--- create pointer to data
>   li   r0, 0
>   stbx r0, r9, r3    <--- data.byte[reg] = 0
>   mr   r3, r4        <--- Oh dear.  Should be "lwz  r3, -8(r1)"
>   blr
>
>
>We've got a "band-aid" fix for this problem -- code in base_alias_check()
>in "alias.c" contains the interesting snippet:
>
> /* If one address is a stack reference there can be no alias;
>    stack references using different base registers do not alias,
>    a stack reference cannot alias a parameter, and a stack reference
>    cannot alias a global.  */
>  if ((GET_CODE (x_base) == ADDRESS && GET_MODE (x_base) == Pmode)
>      || (GET_CODE (y_base) == ADDRESS && GET_MODE (y_base) == Pmode))
>    return 0;
>
>We appear to get aliasing on stack items, so we simply commented out the 
>above snippet, the resulting compilers produce working code.
>
>It'd be interesting to know if any other ports can reproduce this; I had
>a look at the recently reported bugs and there was one MIPS bug which
>might be related.  Anyone got any ideas or suggestions?
>
>Thanks, and
>
>Have Fun!
>
>--turly

Should his example work with egcs/gcc-2.95 then? Or is stack space really
different then?

Franz.