From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Lehmann To: Marc Espie Cc: gcc AT gcc.gnu.org Subject: Re: type based aliasing again Date: Wed, 15 Sep 1999 08:28:00 -0000 Message-id: <19990915154209.A4994@cerebro.laendle> References: <199909141102.NAA18232@quatramaran.ens.fr> <19990915020836.M3983@cerebro.laendle> <199909150903.LAA28886@quatramaran.ens.fr> X-SW-Source: 1999-09/msg00624.html On Wed, Sep 15, 1999 at 11:03:19AM +0200, Marc Espie wrote: > Dubious comparison at best. Completely off the point, in my opinion. > That you even think of it that way strikes me as a fairly strange, careless > philosophy. The asm checks broke things in a plain, visible way: code that > no longer compiles. No, you are wrong. you are talking about the errors that were added at a later point. I was unclear, it wasn't, in fact, the asm changes (these were only new errors), but the changes in other optimizations that made many invalid asms break where they worked before (unter certain circumstances). It was only because so many programs broke that the checks have been added. Which was a very worthwhile thing to do. Just as warnings for the aliasing case would be very worthwhile. I think people believed checking the asm constraints could be very difficult as well. > Whereas aliasing problems are NOT diagnosed by anything else than programs > suddenly stopping working, or exhibiting subtle bugs. Just as the asm breakages. I think your posting indicates the real problem we have about this issue, namely that it's largely misunderstood by most people, maybe even by me. Or not even misunderstood.. it's not clear what the problem is. Whose code broke? And why is this different to any other optimization that caused code to break without any indication (warning, error)? It might well be the case that a very large part of the software breaks, in which case it might be a good idea to disable that optimization, unless we can't come up with good warnings. -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Lehmann To: Marc Espie Cc: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990915154209.A4994@cerebro.laendle> References: <199909141102.NAA18232@quatramaran.ens.fr> <19990915020836.M3983@cerebro.laendle> <199909150903.LAA28886@quatramaran.ens.fr> X-SW-Source: 1999-09n/msg00624.html Message-ID: <19990930180200.KpYg40pX5A1QYHcq22zw9kMUQeVuqxMj17r7UdqGlXc@z> On Wed, Sep 15, 1999 at 11:03:19AM +0200, Marc Espie wrote: > Dubious comparison at best. Completely off the point, in my opinion. > That you even think of it that way strikes me as a fairly strange, careless > philosophy. The asm checks broke things in a plain, visible way: code that > no longer compiles. No, you are wrong. you are talking about the errors that were added at a later point. I was unclear, it wasn't, in fact, the asm changes (these were only new errors), but the changes in other optimizations that made many invalid asms break where they worked before (unter certain circumstances). It was only because so many programs broke that the checks have been added. Which was a very worthwhile thing to do. Just as warnings for the aliasing case would be very worthwhile. I think people believed checking the asm constraints could be very difficult as well. > Whereas aliasing problems are NOT diagnosed by anything else than programs > suddenly stopping working, or exhibiting subtle bugs. Just as the asm breakages. I think your posting indicates the real problem we have about this issue, namely that it's largely misunderstood by most people, maybe even by me. Or not even misunderstood.. it's not clear what the problem is. Whose code broke? And why is this different to any other optimization that caused code to break without any indication (warning, error)? It might well be the case that a very large part of the software breaks, in which case it might be a good idea to disable that optimization, unless we can't come up with good warnings. -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |