From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: patl AT cag.lcs.mit.edu Cc: gcc AT egcs.cygnus.com Subject: Re: __typealias qualifier (was Re: type based aliasing again) Date: Fri, 17 Sep 1999 08:32:00 -0000 Message-id: <19990917083703Q.mitchell@codesourcery.com> References: <199909161908.UAA26066@phal.cygnus.co.uk> <19990916122341J.mitchell@codesourcery.com> X-SW-Source: 1999-09/msg00759.html >>>>> "Patrick" == Patrick J LoPresti writes: mark> I'm not convinced we need to provide a "have your cake and mark> eat it too" mode where you can get the benefits of the mark> optimization without having conforming code. Even if you go mark> to the troule of adding some extra type-qualifiers, mark> attributes, etc., somewhere. Patrick> Are you prepared to be convinced, or have you already Patrick> made up your mind? The former, but I am strongly disinclined on general principles. As if, say, you generally find that when you ride a bicycle you tend to hurt yourself, but now someone promises you won't hurt yourself on this particular snazzy bicycle. I'm willing to listen, but my experience tells me bicycles are dangerous, speaking metaphorically. mark> I'm not commenting on any specific proposal, but it's very, mark> very hard to get new language features right. There tends mark> to be a huge maintenance cost. Patrick> But we *have* a specific proposal, with a precise spec, a Patrick> prototype implementation, and a fair rationale. Why not Patrick> debate that proposal, instead of resorting to general Patrick> arguments? I've been embroiled in *another* debate. My time is limited; I can only devote so much of it to debating. However, I will say that I have yet to see an example that convinces me that even the Linux kernel needs to have its cake and eat it too. THe fast memcpy thing is a bad example; you should work on getting GCC to optimize this for you, instead, via its support for builtin functions, I think. We need the example before even beginning to consider the extension itself. And we need to know why no other alternative already supported by GCC (such as standard ANSI/ISO C, or inline assembly) will do the trick in a satisfactory way. Patrick> This argues against any new extension whatsoever. If Patrick> this is the only argument against `__typealias' and it Patrick> turns out to be suffient, you should probably document Patrick> somewhere that no new GCC extensions will ever be Patrick> accepted. It would save people's time. I think there are very, very few new extensions that we should accept. Especially until we do a really good job implementing and optimizing ANSI/ISO C and C++. It is not in the best interests of the compiler or our users to promulgate odd extensions to GNU C. Portability is an issue, even for GNU programs. Practially, they are sometimes compiled with non-GCC compilers, which often give better performance. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: patl@cag.lcs.mit.edu Cc: gcc@egcs.cygnus.com Subject: Re: __typealias qualifier (was Re: type based aliasing again) Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990917083703Q.mitchell@codesourcery.com> References: <199909161908.UAA26066@phal.cygnus.co.uk> <19990916122341J.mitchell@codesourcery.com> X-SW-Source: 1999-09n/msg00759.html Message-ID: <19990930180200.uQLOQJJCsp3Z4T01hShFaZHfGReMqJsDgWvMhQJW5T4@z> >>>>> "Patrick" == Patrick J LoPresti writes: mark> I'm not convinced we need to provide a "have your cake and mark> eat it too" mode where you can get the benefits of the mark> optimization without having conforming code. Even if you go mark> to the troule of adding some extra type-qualifiers, mark> attributes, etc., somewhere. Patrick> Are you prepared to be convinced, or have you already Patrick> made up your mind? The former, but I am strongly disinclined on general principles. As if, say, you generally find that when you ride a bicycle you tend to hurt yourself, but now someone promises you won't hurt yourself on this particular snazzy bicycle. I'm willing to listen, but my experience tells me bicycles are dangerous, speaking metaphorically. mark> I'm not commenting on any specific proposal, but it's very, mark> very hard to get new language features right. There tends mark> to be a huge maintenance cost. Patrick> But we *have* a specific proposal, with a precise spec, a Patrick> prototype implementation, and a fair rationale. Why not Patrick> debate that proposal, instead of resorting to general Patrick> arguments? I've been embroiled in *another* debate. My time is limited; I can only devote so much of it to debating. However, I will say that I have yet to see an example that convinces me that even the Linux kernel needs to have its cake and eat it too. THe fast memcpy thing is a bad example; you should work on getting GCC to optimize this for you, instead, via its support for builtin functions, I think. We need the example before even beginning to consider the extension itself. And we need to know why no other alternative already supported by GCC (such as standard ANSI/ISO C, or inline assembly) will do the trick in a satisfactory way. Patrick> This argues against any new extension whatsoever. If Patrick> this is the only argument against `__typealias' and it Patrick> turns out to be suffient, you should probably document Patrick> somewhere that no new GCC extensions will ever be Patrick> accepted. It would save people's time. I think there are very, very few new extensions that we should accept. Especially until we do a really good job implementing and optimizing ANSI/ISO C and C++. It is not in the best interests of the compiler or our users to promulgate odd extensions to GNU C. Portability is an issue, even for GNU programs. Practially, they are sometimes compiled with non-GCC compilers, which often give better performance. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com