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

Andi Kleen ak@muc.de
Mon May 24 10:16:00 GMT 1999


On Mon, May 24, 1999 at 06:31:29PM +0200, Jeffrey A Law wrote:
> 
> 
>   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.

What puzzles me is that the aliasing is not flushed on function borders. So I have to 
modify everything so that it sees the union, instead of just fixing a few isolated functions. 
This makes the task a lot more difficult if not impossible without major work.

(Linux generally does not use structure specific prefixes for structure members because it 
was writen to ANSI C, this unfortunately makes it impossible to encapsulate the union in
a few macros in the include file)

It would be useful if gcc could add some special type attribute to make it possible
to localize such changes.

e.g.

struct bla { 
	int a,b;
}; 
struct bla_with_union {
	union { 
		struct bla; 
		int data[2];
	} u;
};


void does_dirty_things(__attribute__((aliased))  struct bla *blub)
{
	struct bla_with_union *bla_union = (struct bla_with_union *) bla; 

	/* play with bla_union */
} 


f()
{
	struct bla blub; 
	
	does_dirty_things(&blub);
	/* flush all aliases to blub here */ 
}

Would this be very hard to implement with the current alias frame work? It would be definitely
very helpful to get older code to play nice with the new optimizer. I could imagine that the
Linux kernel is not the only big piece of code that has such problems.

(I know that the ISO-C comitee shut down a noalias keyword and finally settled with restrict,
although I don't remember the exact reasons, and perhaps in gcc it could be still implemented.
Or something similar that has the same effect)




-Andi

-- 
This is like TV. I don't like TV.


More information about the Gcc-bugs mailing list