From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: Richard Henderson Cc: craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Sat, 05 Jun 1999 09:35:00 -0000 Message-id: References: <19990604150152.A18469@cygnus.com> X-SW-Source: 1999-06/msg00194.html On Fri, 4 Jun 1999, Richard Henderson wrote: > > Doing what you want is actually very hard for GCC right now. Consider > > int i; > short s, *ps = (short *)&i; > i = 0; > s = *ps; Note that while the kernel may contain constructs like the above, I never meant for the "extended rule" to cover them. We'd have to fix them up. The "pointer cast rule" was meant to allow people to know about and override the type-based aliasing - it wasn't meant to handle every single pointer cast automatically being non-aliased. I would consider such behaviour to be basically (a) unimplementable and (b) too non-local. I obviously didn't explain that very well, although I hope my later email about the _implementation_ side explained the details more clearly. The concept was never meant to avoid alias information on any global scale. I think type-based alias information is important. It was meant to be a syntactically simple way to override =specific= instances where the programmer knows he is playing games with typing. As an example, the above sequence obviously has a alia problem as it stands now. My suggestion would _not_ make the above code generate anything different at all. The only thing my suggestion really does is give the programmer a chance to say "oh, I see: the above worked in the original ANSI C, but it does not work with the new one, and I only care about gcc anyway, so I can do the quick fix by just adding the cast": s = *(short *)ps; Note that the cast above in C terms is a no-op: it casts a short pointer to a short pointer, but it would be a way to tell gcc that this access should not be aliased. > Due to a long-ago quirk of history, GCC processes the abstract syntax > tree one statement at a time, so the fact of the cast is long gone by > the time we do the dereference. I agree 100% with the concern you raise, and I'd just like to say that that was never the intention. Having some kind of complete flow would obviously be a very broken concept, and I fully understand the horror people felt if they thought that was what I proposed. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: Richard Henderson Cc: craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: References: <19990604150152.A18469@cygnus.com> X-SW-Source: 1999-06n/msg00194.html Message-ID: <19990630154300.GOnm6I7NY79a5vn9C1ELZtuH2r9gsib1sDfW0d599ik@z> On Fri, 4 Jun 1999, Richard Henderson wrote: > > Doing what you want is actually very hard for GCC right now. Consider > > int i; > short s, *ps = (short *)&i; > i = 0; > s = *ps; Note that while the kernel may contain constructs like the above, I never meant for the "extended rule" to cover them. We'd have to fix them up. The "pointer cast rule" was meant to allow people to know about and override the type-based aliasing - it wasn't meant to handle every single pointer cast automatically being non-aliased. I would consider such behaviour to be basically (a) unimplementable and (b) too non-local. I obviously didn't explain that very well, although I hope my later email about the _implementation_ side explained the details more clearly. The concept was never meant to avoid alias information on any global scale. I think type-based alias information is important. It was meant to be a syntactically simple way to override =specific= instances where the programmer knows he is playing games with typing. As an example, the above sequence obviously has a alia problem as it stands now. My suggestion would _not_ make the above code generate anything different at all. The only thing my suggestion really does is give the programmer a chance to say "oh, I see: the above worked in the original ANSI C, but it does not work with the new one, and I only care about gcc anyway, so I can do the quick fix by just adding the cast": s = *(short *)ps; Note that the cast above in C terms is a no-op: it casts a short pointer to a short pointer, but it would be a way to tell gcc that this access should not be aliased. > Due to a long-ago quirk of history, GCC processes the abstract syntax > tree one statement at a time, so the fact of the cast is long gone by > the time we do the dereference. I agree 100% with the concern you raise, and I'd just like to say that that was never the intention. Having some kind of complete flow would obviously be a very broken concept, and I fully understand the horror people felt if they thought that was what I proposed. Linus