* Re: [patch] beginnings of the macro rewrite [not found] <3900A36C.18989ED4@apple.com> @ 2000-04-21 17:17 ` Horst von Brand 2000-04-22 10:33 ` Zack Weinberg 2000-04-24 23:38 ` Martin Kahlert 0 siblings, 2 replies; 47+ messages in thread From: Horst von Brand @ 2000-04-21 17:17 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 892 bytes --] Stan Shebs <shebs@apple.com> said on gcc-patches: > Zack Weinberg wrote: > > IMPORTANT: This drops support for traditional macros. I will put it > > back if people complain loudly enough. If no one cares then I will > > probably drop -traditional entirely, sometime next week. > > -Wtraditional still works. > It might not get too much reaction on this list, but I suggest > you make this checkin anonymously, so the lynch mob of users > won't be able to come find you. 1/2 :-) > > -traditional will be important to support in GCC for at least > another 10 years, possibly longer, depending on the longevity > of various old code bases. Could somebody enlighten me about what "traditional macros" is being talked here? Thanks! -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-21 17:17 ` [patch] beginnings of the macro rewrite Horst von Brand @ 2000-04-22 10:33 ` Zack Weinberg 2000-04-22 20:13 ` Marc Espie ` (3 more replies) 2000-04-24 23:38 ` Martin Kahlert 1 sibling, 4 replies; 47+ messages in thread From: Zack Weinberg @ 2000-04-22 10:33 UTC (permalink / raw) To: Horst von Brand; +Cc: gcc On Fri, Apr 21, 2000 at 04:15:54PM -0400, Horst von Brand wrote: > Stan Shebs <shebs@apple.com> said on gcc-patches: > > Zack Weinberg wrote: > > > IMPORTANT: This drops support for traditional macros. I will put it > > > back if people complain loudly enough. If no one cares then I will > > > probably drop -traditional entirely, sometime next week. > > > -Wtraditional still works. > > > It might not get too much reaction on this list, but I suggest > > you make this checkin anonymously, so the lynch mob of users > > won't be able to come find you. 1/2 :-) > > > > -traditional will be important to support in GCC for at least > > another 10 years, possibly longer, depending on the longevity > > of various old code bases. > > Could somebody enlighten me about what "traditional macros" is being talked > here? K+R has significantly different semantics for macro expansion from standard C. Highlights include: - macros are not disabled during their own expansions. The practical effect is that #define EPERM EPERM will cause infinite recursion if you use EPERM anywhere. There are some perverse cases where it might actually be useful, though. - macro arguments are expanded even inside strings and character constants (but no effort is made to quote special characters). - the # and ## (stringize and paste) operators are not available. - comments are replaced by nothing _after_ arguments are substituted, which means /**/ can be used to paste tokens. - there is no special protection against accidental token paste; if you write #define foo(x) x+b foo(+); you'll get ++b; instead of + +b; zw ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-22 10:33 ` Zack Weinberg @ 2000-04-22 20:13 ` Marc Espie 2000-04-22 20:20 ` Neil Booth ` (2 subsequent siblings) 3 siblings, 0 replies; 47+ messages in thread From: Marc Espie @ 2000-04-22 20:13 UTC (permalink / raw) To: zack; +Cc: egcs In article < 20000422103307.C8273@wolery.cumb.org > you write: >On Fri, Apr 21, 2000 at 04:15:54PM -0400, Horst von Brand wrote: >> Stan Shebs <shebs@apple.com> said on gcc-patches: >> > Zack Weinberg wrote: >> > > IMPORTANT: This drops support for traditional macros. I will put it >> > > back if people complain loudly enough. If no one cares then I will >> > > probably drop -traditional entirely, sometime next week. >> > > -Wtraditional still works. >> >> > It might not get too much reaction on this list, but I suggest >> > you make this checkin anonymously, so the lynch mob of users >> > won't be able to come find you. 1/2 :-) >> > >> > -traditional will be important to support in GCC for at least >> > another 10 years, possibly longer, depending on the longevity >> > of various old code bases. [...] >- comments are replaced by nothing _after_ arguments are substituted, > which means /**/ can be used to paste tokens. I'm somewhat behind on current gcc discussion, but I agree 110% with Stan there. *If* you drop traditional macro support from cpplib, then that means that a whole host of vendors will have to resort to, either keep an older version of GNU cpp around (which you probably don't want, thanks to the improvements you've done), or switch *definitively* to a smaller, no-thrills-but-no-surprise-either cpp. This is probably not quite the effect you're looking for... Personally, I don't care much for traditional cpp, but most OSes still have dark corners, where code that needs it lurks... Granted, postponing the rewrite forever is not a good idea, but we would rather make the decision by ourselves than having it forced down our collective throats. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-22 10:33 ` Zack Weinberg 2000-04-22 20:13 ` Marc Espie @ 2000-04-22 20:20 ` Neil Booth 2000-04-24 8:57 ` Michael Meissner 2000-04-27 15:54 ` Philipp Thomas 3 siblings, 0 replies; 47+ messages in thread From: Neil Booth @ 2000-04-22 20:20 UTC (permalink / raw) To: Zack Weinberg; +Cc: Horst von Brand, gcc Zack Weinberg wrote:- > K+R has significantly different semantics for macro expansion from > standard C. Highlights include: How about warning very noisily whenever traditional macro behaviour is relied on, including a warning it will not be supported in some future version? The best we can try and do is gee people up who rely on it. Neil. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-22 10:33 ` Zack Weinberg 2000-04-22 20:13 ` Marc Espie 2000-04-22 20:20 ` Neil Booth @ 2000-04-24 8:57 ` Michael Meissner 2000-04-24 17:54 ` Russ Allbery 2000-04-27 15:54 ` Philipp Thomas 3 siblings, 1 reply; 47+ messages in thread From: Michael Meissner @ 2000-04-24 8:57 UTC (permalink / raw) To: Zack Weinberg; +Cc: Horst von Brand, gcc On Sat, Apr 22, 2000 at 10:33:07AM -0700, Zack Weinberg wrote: > - macros are not disabled during their own expansions. The practical > effect is that > > #define EPERM EPERM Yes, obviously people never did this with the traditional cpp. > will cause infinite recursion if you use EPERM anywhere. There are > some perverse cases where it might actually be useful, though. > > - macro arguments are expanded even inside strings and character > constants (but no effort is made to quote special characters). > > - the # and ## (stringize and paste) operators are not available. > > - comments are replaced by nothing _after_ arguments are substituted, > which means /**/ can be used to paste tokens. > > - there is no special protection against accidental token paste; if > you write > > #define foo(x) x+b > foo(+); > > you'll get ++b; instead of + +b; A lot of the above is needed by people who invoke cpp to handle preprocessing outside of the compiler. For example, xrdb uses the preprocessor to process ifdef's in the resources file (a feature I happen to use so I can adjust the sizes of windows based on the screen size). I believe X's xmkmf also uses the standard preprocessor to create a Makefile from an Imakefile. I know in the past perl 4.036 used it too, but I don't know if modern perl's currently use it. -- Michael Meissner, Cygnus Solutions, a Red Hat company. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-24 8:57 ` Michael Meissner @ 2000-04-24 17:54 ` Russ Allbery 0 siblings, 0 replies; 47+ messages in thread From: Russ Allbery @ 2000-04-24 17:54 UTC (permalink / raw) To: gcc Michael Meissner <meissner@cygnus.com> writes: > I know in the past perl 4.036 used it too, but I don't know if modern > perl's currently use it. It's still there: -P causes your script to be run through the C preprocessor before compilation by Perl. (Because both comments and cpp directives begin with the # character, you should avoid starting comments with any words recognized by the C preprocessor such as "if", "else", or "define".) These days, it's mostly only used for very special applications and obfuscated code, as the C preprocessor isn't really designed for preprocessing other languages (some Perl constructs confuse it), and of course Perl's use of # as a comment character conflicts pretty badly with the use of the preprocessor. -- Russ Allbery (rra@stanford.edu) < http://www.eyrie.org/~eagle/ > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-22 10:33 ` Zack Weinberg ` (2 preceding siblings ...) 2000-04-24 8:57 ` Michael Meissner @ 2000-04-27 15:54 ` Philipp Thomas 2000-04-27 17:32 ` Joe Buck 3 siblings, 1 reply; 47+ messages in thread From: Philipp Thomas @ 2000-04-27 15:54 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc * Zack Weinberg (zack@wolery.cumb.org) [20000422 19:33]: > K+R has significantly different semantics for macro expansion from > standard C. And I'll bet rather highly that removing support for -traditional will break compilation of X or X apps that use imakefiles. I haven't tried compiling XFree86 with 2.96 lately, but the last time I tried it woudn't work. Granted, using the C preprocessor to construct makefiles isn't exactly a good idea. Now that 2.96s preprocessor is much pickier, some tricks won't work. At least IMO we *must* provide a way to keep cpp usable for the imake configury, be that -traditional or any other flag that dumbs down cpp enough. Philipp -- Philipp Thomas <pthomas@suse.de> Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany #define NINODE 50 /* number of in core inodes */ #define NPROC 30 /* max number of processes */ -- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-27 15:54 ` Philipp Thomas @ 2000-04-27 17:32 ` Joe Buck 0 siblings, 0 replies; 47+ messages in thread From: Joe Buck @ 2000-04-27 17:32 UTC (permalink / raw) To: Philipp Thomas; +Cc: Zack Weinberg, gcc > And I'll bet rather highly that removing support for -traditional will break > compilation of X or X apps that use imakefiles. Yes, this is one of the main reasons why we cannot drop -traditional (the Imakefile use plus many other inappropriate-but-well-established misuses of the C preprocessor). Don't worry, the issue is pretty much closed for now. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite 2000-04-21 17:17 ` [patch] beginnings of the macro rewrite Horst von Brand 2000-04-22 10:33 ` Zack Weinberg @ 2000-04-24 23:38 ` Martin Kahlert 1 sibling, 0 replies; 47+ messages in thread From: Martin Kahlert @ 2000-04-24 23:38 UTC (permalink / raw) To: gcc Quoting Horst von Brand (vonbrand@sleipnir.valparaiso.cl): > Stan Shebs <shebs@apple.com> said on gcc-patches: > > Zack Weinberg wrote: > > > IMPORTANT: This drops support for traditional macros. I will put it > > > back if people complain loudly enough. If no one cares then I will > > > probably drop -traditional entirely, sometime next week. > > > -Wtraditional still works. > > > It might not get too much reaction on this list, but I suggest > > you make this checkin anonymously, so the lynch mob of users > > won't be able to come find you. 1/2 :-) > > > > -traditional will be important to support in GCC for at least > > another 10 years, possibly longer, depending on the longevity > > of various old code bases. > > Could somebody enlighten me about what "traditional macros" is being talked > here? And: does this affect Fortran? Preprocessing fortran sources (*.F files) relies on -traditional i think: The problem are in comments with 's in them: C I'm a comment and string concatenation like WRITE(*,*) 'HELLO ' // 'WORLD' I don't know much about this issues, but i know, that Compaq's free Fortran compiler for Linux Alpha uses/used gcc's preprocessor and it had problems with exactly the above mentioned things. Bye, Martin. -- The early bird gets the worm. If you want something else for breakfast, get up later. -- The early bird gets the worm. If you want something else for breakfast, get up later. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [patch] beginnings of the macro rewrite @ 2000-04-23 4:04 Richard Kenner 0 siblings, 0 replies; 47+ messages in thread From: Richard Kenner @ 2000-04-23 4:04 UTC (permalink / raw) To: NeilB; +Cc: gcc How about warning very noisily whenever traditional macro behaviour is relied on, including a warning it will not be supported in some future version? The best we can try and do is gee people up who rely on it. Seems pointless to me. The traditional code won't be able to be removed in any of our lifetimes. ^ permalink raw reply [flat|nested] 47+ messages in thread
* C++ binary compatibility between GCC 3.1 and GCC 3.2? @ 2002-07-04 9:55 Andreas Jaeger 2002-07-04 10:23 ` H. J. Lu ` (3 more replies) 0 siblings, 4 replies; 47+ messages in thread From: Andreas Jaeger @ 2002-07-04 9:55 UTC (permalink / raw) To: gcc Jason committed recently patch to fix a number of C++ Bugs in the ABI: http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01275.html What does this mean for binary compatibility between GCC 3.1 and GCC 3.2? With the introduction of GCC 3 and its ABI, the expectation by users is that we won't have binary incompatible changes. Unfortunatly the - AFAIK valid - bug reports show that the ABI implemention was buggy and therefore needed to change. What will this mean for distributions and for production usage of GCC 3.1? I fear this means that folks cannot easily upgrade from GCC 3.1 to GCC 3.2 since C++ is incompatible and all C++ libraries that are needed for development need to be relinked. Would it make sense for a distribution starting to ship GCC 3.1 to apply that bugfix? I prefer not to do this since it would mean that then two different GCC 3.1 release are binary incompatible :-(. But it would allow an easier upgrade to GCC 3.2 - or distributors are stuck with GCC 3.1 like some where stuck with GCC 2.95 due to the binary incompatibilities between 2.95, 3.0 and 3.1 which were known before. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-04 9:55 C++ binary compatibility between GCC 3.1 and GCC 3.2? Andreas Jaeger @ 2002-07-04 10:23 ` H. J. Lu 2002-07-05 14:17 ` Mark Mitchell ` (2 subsequent siblings) 3 siblings, 0 replies; 47+ messages in thread From: H. J. Lu @ 2002-07-04 10:23 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc On Thu, Jul 04, 2002 at 06:35:06PM +0200, Andreas Jaeger wrote: > > Would it make sense for a distribution starting to ship GCC 3.1 to > apply that bugfix? I prefer not to do this since it would mean that If it is true, those bug fixes should be moved into gcc 3.1 after verifying they are really ok. At least, there should be a gcc 3 clearing house for Linux for those kinds of ABI issuses so that there is a hope for a compatible C++ implememntation among different Linux distributions. H.J. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-04 9:55 C++ binary compatibility between GCC 3.1 and GCC 3.2? Andreas Jaeger 2002-07-04 10:23 ` H. J. Lu @ 2002-07-05 14:17 ` Mark Mitchell 2002-07-05 14:22 ` Andreas Jaeger 2002-07-05 14:46 ` David O'Brien 2002-07-05 22:35 ` David Edelsohn 2002-07-06 5:40 ` Joseph S. Myers 3 siblings, 2 replies; 47+ messages in thread From: Mark Mitchell @ 2002-07-05 14:17 UTC (permalink / raw) To: Andreas Jaeger, gcc > What does this mean for binary compatibility between GCC 3.1 and GCC > 3.2? With the introduction of GCC 3 and its ABI, the expectation by > users is that we won't have binary incompatible changes. Unfortunatly > the - AFAIK valid - bug reports show that the ABI implemention was > buggy and therefore needed to change. Yes, the implementation had some bugs. It was also the case that the ABI specification had some bugs/omissions/unclarities. (The most recent substantive change to the ABI specification occurred about a week ago.) There are getting to be fewer and fewer bugs and the rate of change to the ABI is approaching zero, but I, like you, am disappointed that we're still breaking the C++ ABI between major releases of the compiler. In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible with respect to the C++ ABI. I can't say what that might mean as a distributor. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:17 ` Mark Mitchell @ 2002-07-05 14:22 ` Andreas Jaeger 2002-07-05 14:28 ` Mark Mitchell 2002-07-05 14:46 ` David O'Brien 1 sibling, 1 reply; 47+ messages in thread From: Andreas Jaeger @ 2002-07-05 14:22 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell <mark@codesourcery.com> writes: >> What does this mean for binary compatibility between GCC 3.1 and GCC >> 3.2? With the introduction of GCC 3 and its ABI, the expectation by >> users is that we won't have binary incompatible changes. Unfortunatly >> the - AFAIK valid - bug reports show that the ABI implemention was >> buggy and therefore needed to change. > > Yes, the implementation had some bugs. It was also the case that the > ABI specification had some bugs/omissions/unclarities. (The most recent > substantive change to the ABI specification occurred about a week ago.) > > There are getting to be fewer and fewer bugs and the rate of change to > the ABI is approaching zero, but I, like you, am disappointed that we're > still breaking the C++ ABI between major releases of the compiler. > > In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible > with respect to the C++ ABI. How severe is this? Will people encounter this in every day code or is only in some esoteric situations? > I can't say what that might mean as a distributor. Putting on my distributor hat - and answering without much thinking about all the implications - it would be better to have 3.1.1 and 3.2 compatible (with the cost of 3.1 and 3.1.1 not compatible to each other). Alternativly we could rename GCC 3.1.1 to GCC 3.2.1 and release that in a few weeks time (this would imply to rename mainline to GCC 3.3 prerelease and have GCC 3.3 release in autumn). As you see, I haven't made my up mind and do not know what the best solution is here. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:22 ` Andreas Jaeger @ 2002-07-05 14:28 ` Mark Mitchell 2002-07-05 14:53 ` David O'Brien 0 siblings, 1 reply; 47+ messages in thread From: Mark Mitchell @ 2002-07-05 14:28 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc >> In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible >> with respect to the C++ ABI. > > How severe is this? Will people encounter this in every day code or > is only in some esoteric situations? Questions like this are always difficult to answer. I would lean towards "only in some esoteric situations", but of course that depends on exactly what you consider esoteric. >> I can't say what that might mean as a distributor. > > Putting on my distributor hat - and answering without much thinking > about all the implications - it would be better to have 3.1.1 and 3.2 > compatible (with the cost of 3.1 and 3.1.1 not compatible to each > other). This bit has already been decided. We will not break compatibility between minor releases (3.1 and 3.1.1) unless it is absolutely necessary. I don't think renumbering is going to help a lot. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:28 ` Mark Mitchell @ 2002-07-05 14:53 ` David O'Brien 2002-07-05 15:08 ` Mark Mitchell 2002-07-06 6:19 ` Daniel Egger 0 siblings, 2 replies; 47+ messages in thread From: David O'Brien @ 2002-07-05 14:53 UTC (permalink / raw) To: Mark Mitchell; +Cc: Andreas Jaeger, gcc On Fri, Jul 05, 2002 at 01:11:10PM -0700, Mark Mitchell wrote: > >> In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible > >> with respect to the C++ ABI. > > How severe is this? Will people encounter this in every day code or > > is only in some esoteric situations? ... > I would lean towards "only in some esoteric situations", but of course > that depends on exactly what you consider esoteric. Would we see it in KDE and GNOME and all the related C++ libs there? > > it would be better to have 3.1.1 and 3.2 compatible (with the cost of > > 3.1 and 3.1.1 not compatible to each other). > > This bit has already been decided. We will not break compatibility > between minor releases (3.1 and 3.1.1) unless it is absolutely > necessary. I don't think renumbering is going to help a lot. Why not put the decision in the hands of the distributors? Offer both 3.1 and 3.2 C++ ABI's and let the vendor pick the one they want with a #define. I dare say all the distributors feel this way -- all the existing versions out there use GCC 2.95.3[+], or the RedHat 2.96. All of which are binary incompatible with 3.x. FreeBSD will be using 3.1.1 in our 5.0 release; and I've heard plans from some Linux distributions to use 3.1.1 in their next release also. -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:53 ` David O'Brien @ 2002-07-05 15:08 ` Mark Mitchell 2002-07-06 5:34 ` Andreas Jaeger 2002-07-06 6:19 ` Daniel Egger 1 sibling, 1 reply; 47+ messages in thread From: Mark Mitchell @ 2002-07-05 15:08 UTC (permalink / raw) To: obrien; +Cc: Andreas Jaeger, gcc --On Friday, July 05, 2002 02:33:53 PM -0700 David O'Brien <obrien@freebsd.org> wrote: > On Fri, Jul 05, 2002 at 01:11:10PM -0700, Mark Mitchell wrote: >> >> In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible >> >> with respect to the C++ ABI. >> > How severe is this? Will people encounter this in every day code or >> > is only in some esoteric situations? > ... >> I would lean towards "only in some esoteric situations", but of course >> that depends on exactly what you consider esoteric. > > Would we see it in KDE and GNOME and all the related C++ libs there? I don't think anybody knows. >> > it would be better to have 3.1.1 and 3.2 compatible (with the cost of >> > 3.1 and 3.1.1 not compatible to each other). >> >> This bit has already been decided. We will not break compatibility >> between minor releases (3.1 and 3.1.1) unless it is absolutely >> necessary. I don't think renumbering is going to help a lot. > > Why not put the decision in the hands of the distributors? Offer both > 3.1 and 3.2 C++ ABI's and let the vendor pick the one they want with a ># define. Because our goal is to produce minor releases that fix critical bugs. Adding in new, not nearly as well-tested ABI changes, one week for a release is simply not going to happen. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 15:08 ` Mark Mitchell @ 2002-07-06 5:34 ` Andreas Jaeger 2002-07-06 6:40 ` Gabriel Dos Reis 0 siblings, 1 reply; 47+ messages in thread From: Andreas Jaeger @ 2002-07-06 5:34 UTC (permalink / raw) To: Mark Mitchell; +Cc: obrien, gcc Mark Mitchell <mark@codesourcery.com> writes: > --On Friday, July 05, 2002 02:33:53 PM -0700 David O'Brien > <obrien@freebsd.org> wrote: > >> On Fri, Jul 05, 2002 at 01:11:10PM -0700, Mark Mitchell wrote: >>> >> In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible >>> >> with respect to the C++ ABI. >>> > How severe is this? Will people encounter this in every day code or >>> > is only in some esoteric situations? >> ... >>> I would lean towards "only in some esoteric situations", but of course >>> that depends on exactly what you consider esoteric. >> >> Would we see it in KDE and GNOME and all the related C++ libs there? > > I don't think anybody knows. > >>> > it would be better to have 3.1.1 and 3.2 compatible (with the cost of >>> > 3.1 and 3.1.1 not compatible to each other). >>> >>> This bit has already been decided. We will not break compatibility >>> between minor releases (3.1 and 3.1.1) unless it is absolutely >>> necessary. I don't think renumbering is going to help a lot. >> >> Why not put the decision in the hands of the distributors? Offer both >> 3.1 and 3.2 C++ ABI's and let the vendor pick the one they want with a >># define. That would mean incompatibility between 3.1. versions - my self compiled 3.1.1 compiler would be incompatible to your self-compiled 3.1.1 compiler :-(. > > Because our goal is to produce minor releases that fix critical bugs. > > Adding in new, not nearly as well-tested ABI changes, one week for a > release is simply not going to happen. What about postponing this change for 3.1.2 - with possible renaming it to 3.2.2 - with the goal to be compatible to GCC mainline? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 5:34 ` Andreas Jaeger @ 2002-07-06 6:40 ` Gabriel Dos Reis 2002-07-06 6:40 ` Jakub Jelinek 0 siblings, 1 reply; 47+ messages in thread From: Gabriel Dos Reis @ 2002-07-06 6:40 UTC (permalink / raw) To: Mark Mitchell; +Cc: obrien, gcc Andreas Jaeger <aj@suse.de> writes: | > Because our goal is to produce minor releases that fix critical bugs. | > | > Adding in new, not nearly as well-tested ABI changes, one week for a | > release is simply not going to happen. | | What about postponing this change for 3.1.2 - That would make an ABI incompatibility in minor releases. That is worst than incompatibility between major releases. | with possible renaming | it to 3.2.2 - with the goal to be compatible to GCC mainline? I raise the same objection. Minor releases should not introduce ABI incompatibilities. They should just feature non-ABI breaking bug fixes. -- Gaby ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 6:40 ` Gabriel Dos Reis @ 2002-07-06 6:40 ` Jakub Jelinek 2002-07-06 7:20 ` Gabriel Dos Reis 2002-07-06 7:42 ` Andreas Jaeger 0 siblings, 2 replies; 47+ messages in thread From: Jakub Jelinek @ 2002-07-06 6:40 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Mark Mitchell, obrien, gcc On Sat, Jul 06, 2002 at 02:32:55PM +0200, Gabriel Dos Reis wrote: > | > Because our goal is to produce minor releases that fix critical bugs. > | > > | > Adding in new, not nearly as well-tested ABI changes, one week for a > | > release is simply not going to happen. > | > | What about postponing this change for 3.1.2 - > > That would make an ABI incompatibility in minor releases. That is > worst than incompatibility between major releases. > > | with possible renaming > | it to 3.2.2 - with the goal to be compatible to GCC mainline? > > I raise the same objection. Minor releases should not introduce ABI > incompatibilities. They should just feature non-ABI breaking bug > fixes. But if 3.1.2 was called 3.2, it would not be minor release but major, thus could introduce ABI incompatibilities. Apple could stay at 3.1, while Linux vendors, FreeBSD and whoever is currently preparing 3.1.x based distribution could still switch to this 3.2 and be (hopefully) binary compatible with the upcoming 3.3 (current trunk). Jakub ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 6:40 ` Jakub Jelinek @ 2002-07-06 7:20 ` Gabriel Dos Reis 2002-07-06 7:53 ` Andreas Jaeger 2002-07-06 7:42 ` Andreas Jaeger 1 sibling, 1 reply; 47+ messages in thread From: Gabriel Dos Reis @ 2002-07-06 7:20 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Mark Mitchell, obrien, gcc Jakub Jelinek <jakub@redhat.com> writes: | But if 3.1.2 was called 3.2, it would not be minor release but major, thus | could introduce ABI incompatibilities. As I understand people are objecting to having 3.1.x not binrary compatible with 3.2.y. | Apple could stay at 3.1, while Linux vendors, FreeBSD and whoever | is currently preparing 3.1.x based distribution could still switch to this | 3.2 and be (hopefully) binary compatible with the upcoming 3.3 | (current trunk). -- Gaby ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 7:20 ` Gabriel Dos Reis @ 2002-07-06 7:53 ` Andreas Jaeger 2002-07-06 8:54 ` Gabriel Dos Reis 2002-07-06 11:04 ` Daniel Jacobowitz 0 siblings, 2 replies; 47+ messages in thread From: Andreas Jaeger @ 2002-07-06 7:53 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Jakub Jelinek, Mark Mitchell, obrien, gcc Gabriel Dos Reis <gdr@codesourcery.com> writes: > Jakub Jelinek <jakub@redhat.com> writes: > > | But if 3.1.2 was called 3.2, it would not be minor release but major, thus > | could introduce ABI incompatibilities. > > As I understand people are objecting to having 3.1.x not binrary > compatible with 3.2.y. The problem is that people are soon going to use 3.1.x in production environments. If we switch today to 3.1, we're stuck with it, since it will be binary incompatible to later versions. But if a release [1] from the 3.1 branch happens that ensures binary compatibilty with later GCC versions - and this happens in the next few weeks, I expect that the communities can switch to that version. This should solve at least the problems I have at SuSE. Andreas Footnotes: [1] Note I don't give a version number here. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 7:53 ` Andreas Jaeger @ 2002-07-06 8:54 ` Gabriel Dos Reis 2002-07-06 11:04 ` Daniel Jacobowitz 1 sibling, 0 replies; 47+ messages in thread From: Gabriel Dos Reis @ 2002-07-06 8:54 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Mark Mitchell, obrien, gcc Andreas Jaeger <aj@suse.de> writes: | Gabriel Dos Reis <gdr@codesourcery.com> writes: | | > Jakub Jelinek <jakub@redhat.com> writes: | > | > | But if 3.1.2 was called 3.2, it would not be minor release but major, thus | > | could introduce ABI incompatibilities. | > | > As I understand people are objecting to having 3.1.x not binrary | > compatible with 3.2.y. | | The problem is that people are soon going to use 3.1.x in production | environments. If we switch today to 3.1, we're stuck with it, since | it will be binary incompatible to later versions. But if a release | [1] from the 3.1 branch happens that ensures binary compatibilty with | later GCC versions - and this happens in the next few weeks, I expect | that the communities can switch to that version. This should solve at | least the problems I have at SuSE. Thanks for the clarifications. So all that needs is to make an exception to our earlier commitment that minor releases won't introduce ABI incompatibility; or make an exception to our scheduled development plan. I don't have any strong opinion. But if we were not to follow our developement schedule (as proposed by Jakub) we have better to be sure that nearly all ABI bugs are fixed in 3.2 (or we will face the same problem later). Given the time-frame I'm not sure we have enought latitude to do that... -- Gaby ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 7:53 ` Andreas Jaeger 2002-07-06 8:54 ` Gabriel Dos Reis @ 2002-07-06 11:04 ` Daniel Jacobowitz 1 sibling, 0 replies; 47+ messages in thread From: Daniel Jacobowitz @ 2002-07-06 11:04 UTC (permalink / raw) To: Andreas Jaeger Cc: Gabriel Dos Reis, Jakub Jelinek, Mark Mitchell, obrien, gcc On Sat, Jul 06, 2002 at 03:44:35PM +0200, Andreas Jaeger wrote: > Gabriel Dos Reis <gdr@codesourcery.com> writes: > > > Jakub Jelinek <jakub@redhat.com> writes: > > > > | But if 3.1.2 was called 3.2, it would not be minor release but major, thus > > | could introduce ABI incompatibilities. > > > > As I understand people are objecting to having 3.1.x not binrary > > compatible with 3.2.y. > > The problem is that people are soon going to use 3.1.x in production > environments. If we switch today to 3.1, we're stuck with it, since > it will be binary incompatible to later versions. But if a release > [1] from the 3.1 branch happens that ensures binary compatibilty with > later GCC versions - and this happens in the next few weeks, I expect > that the communities can switch to that version. This should solve at > least the problems I have at SuSE. > > Andreas > > Footnotes: > [1] Note I don't give a version number here. On the Debian side, we're starting to organize a move from gcc 2.95 to a 3.1-branch compiler as the system compiler, with hopes to do it in the next couple of months. Changing compilers in such a way as to break the C++ ABI is a gargantuan effort for a continually-updating system like Debian's unstable distribution, and I expect it to be a very painful process. Not something I want to do more than once. On the other hand, I'm not terribly concerned here. These sound like bugs which we can easily resolve on a case-by-case basis if they actually manifest in a given library's interfaces, rare enough that we won't need the sort of all-at-once effort that v2->v3 is going to require. [I speak for no man and no company] -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 6:40 ` Jakub Jelinek 2002-07-06 7:20 ` Gabriel Dos Reis @ 2002-07-06 7:42 ` Andreas Jaeger 2002-07-06 11:08 ` Jeff Law 1 sibling, 1 reply; 47+ messages in thread From: Andreas Jaeger @ 2002-07-06 7:42 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Gabriel Dos Reis, Mark Mitchell, obrien, gcc Jakub Jelinek <jakub@redhat.com> writes: > On Sat, Jul 06, 2002 at 02:32:55PM +0200, Gabriel Dos Reis wrote: >> | > Because our goal is to produce minor releases that fix critical bugs. >> | > >> | > Adding in new, not nearly as well-tested ABI changes, one week for a >> | > release is simply not going to happen. >> | >> | What about postponing this change for 3.1.2 - >> >> That would make an ABI incompatibility in minor releases. That is >> worst than incompatibility between major releases. >> >> | with possible renaming >> | it to 3.2.2 - with the goal to be compatible to GCC mainline? >> >> I raise the same objection. Minor releases should not introduce ABI >> incompatibilities. They should just feature non-ABI breaking bug >> fixes. > > But if 3.1.2 was called 3.2, it would not be minor release but major, thus > could introduce ABI incompatibilities. > Apple could stay at 3.1, while Linux vendors, FreeBSD and whoever > is currently preparing 3.1.x based distribution could still switch to this > 3.2 and be (hopefully) binary compatible with the upcoming 3.3 > (current trunk). I agree with you, Jakub. Who would be interested in such a switch? FreeBSD and SuSE seem to be interested. What about Linux distributors, e.g. Red Hat and other OSes? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 7:42 ` Andreas Jaeger @ 2002-07-06 11:08 ` Jeff Law 2002-07-06 11:10 ` Gwenole Beauchesne 0 siblings, 1 reply; 47+ messages in thread From: Jeff Law @ 2002-07-06 11:08 UTC (permalink / raw) To: Andreas Jaeger Cc: Jakub Jelinek, Gabriel Dos Reis, Mark Mitchell, obrien, gcc In message <u8y9cprn65.fsf@gromit.moeb>, Andreas Jaeger writes: >Jakub Jelinek <jakub@redhat.com> writes: >I agree with you, Jakub. > >Who would be interested in such a switch? FreeBSD and SuSE seem to be >interested. What about Linux distributors, e.g. Red Hat and other >OSes? We're definitely interested. And like SuSE, if we could get the bits in July they would be useful, if they don't arrive until September, then they would not be useful. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 11:08 ` Jeff Law @ 2002-07-06 11:10 ` Gwenole Beauchesne 0 siblings, 0 replies; 47+ messages in thread From: Gwenole Beauchesne @ 2002-07-06 11:10 UTC (permalink / raw) To: law Cc: Andreas Jaeger, Jakub Jelinek, Gabriel Dos Reis, Mark Mitchell, obrien, gcc Hi, > In message <u8y9cprn65.fsf@gromit.moeb>, Andreas Jaeger writes: >> Jakub Jelinek <jakub@redhat.com> writes: >> I agree with you, Jakub. >> >> Who would be interested in such a switch? FreeBSD and SuSE seem to be >> interested. What about Linux distributors, e.g. Red Hat and other >> OSes? > We're definitely interested. And like SuSE, if we could get the bits in > July they would be useful, if they don't arrive until September, then > they > would not be useful. Likewise to Red Hat and SuSE, we are interested in those changes/switch too. And September would be too late as well. Bye, Gwenole, sorry to aol'izing. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:53 ` David O'Brien 2002-07-05 15:08 ` Mark Mitchell @ 2002-07-06 6:19 ` Daniel Egger 1 sibling, 0 replies; 47+ messages in thread From: Daniel Egger @ 2002-07-06 6:19 UTC (permalink / raw) To: obrien; +Cc: GCC Developer Mailinglist Am Fre, 2002-07-05 um 23.33 schrieb David O'Brien: > Would we see it in KDE and GNOME and all the related C++ libs there? You can trivially count the GNOME applications and libraries written in C++ with your hands. KDE might be much more of a problem here escpecially since they're driving gcc at its maximum in the hope to get fast and small binaries. -- Servus, Daniel ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:17 ` Mark Mitchell 2002-07-05 14:22 ` Andreas Jaeger @ 2002-07-05 14:46 ` David O'Brien 2002-07-05 15:02 ` H. J. Lu ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: David O'Brien @ 2002-07-05 14:46 UTC (permalink / raw) To: Mark Mitchell; +Cc: Andreas Jaeger, gcc, Gerald Pfeifer On Fri, Jul 05, 2002 at 12:51:17PM -0700, Mark Mitchell wrote: > In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible > with respect to the C++ ABI. > > I can't say what that might mean as a distributor. I can -- MAJOR pain and difficulty. It would probably prevent FreeBSD using GCC 3.2 in our 5.1 and later 5.x releases. That means 1-2 years before the compiler can be upgraded for our users. I urge you as strongly as I can to back port (#define wrap if needed) the changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 and can take ABI hits right now. -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:46 ` David O'Brien @ 2002-07-05 15:02 ` H. J. Lu 2002-07-05 15:12 ` David O'Brien 2002-07-05 15:02 ` Mark Mitchell 2002-07-06 4:56 ` Andreas Jaeger 2 siblings, 1 reply; 47+ messages in thread From: H. J. Lu @ 2002-07-05 15:02 UTC (permalink / raw) To: David O'Brien; +Cc: Mark Mitchell, Andreas Jaeger, gcc, Gerald Pfeifer On Fri, Jul 05, 2002 at 02:28:38PM -0700, David O'Brien wrote: > On Fri, Jul 05, 2002 at 12:51:17PM -0700, Mark Mitchell wrote: > > In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible > > with respect to the C++ ABI. > > > > I can't say what that might mean as a distributor. > > I can -- MAJOR pain and difficulty. It would probably prevent FreeBSD > using GCC 3.2 in our 5.1 and later 5.x releases. That means 1-2 years > before the compiler can be upgraded for our users. > > I urge you as strongly as I can to back port (#define wrap if needed) the > changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with > GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] > and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 > and can take ABI hits right now. > IMHO, keep the C++ ABI compatibility between 3.1 and 3.1.x, but break between 3.1.x and 3.2, is one of the worst things anyone can do to gcc. H.J. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 15:02 ` H. J. Lu @ 2002-07-05 15:12 ` David O'Brien 2002-07-05 15:20 ` H. J. Lu 0 siblings, 1 reply; 47+ messages in thread From: David O'Brien @ 2002-07-05 15:12 UTC (permalink / raw) To: H. J. Lu; +Cc: Mark Mitchell, Andreas Jaeger, gcc, Gerald Pfeifer On Fri, Jul 05, 2002 at 02:35:34PM -0700, H. J. Lu wrote: > IMHO, keep the C++ ABI compatibility between 3.1 and 3.1.x, but break > between 3.1.x and 3.2, is one of the worst things anyone can do to gcc. Why? Both Andreas said that the change happening 3.1.1->3.2 will cause problems in upcoming OS releases. You didn't give any reasoning for your position. -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 15:12 ` David O'Brien @ 2002-07-05 15:20 ` H. J. Lu 2002-07-05 16:11 ` Stan Shebs 0 siblings, 1 reply; 47+ messages in thread From: H. J. Lu @ 2002-07-05 15:20 UTC (permalink / raw) To: David O'Brien; +Cc: Mark Mitchell, Andreas Jaeger, gcc, Gerald Pfeifer On Fri, Jul 05, 2002 at 02:46:11PM -0700, David O'Brien wrote: > On Fri, Jul 05, 2002 at 02:35:34PM -0700, H. J. Lu wrote: > > IMHO, keep the C++ ABI compatibility between 3.1 and 3.1.x, but break > > between 3.1.x and 3.2, is one of the worst things anyone can do to gcc. > > Why? Both Andreas said that the change happening 3.1.1->3.2 will cause > problems in upcoming OS releases. You didn't give any reasoning for your > position. My position is I doubt many people really case the C++ ABI compatibility between 3.1 and 3.1.1, at least I don't. I can even pretend 3.1 never existed :-(. H.J. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 15:20 ` H. J. Lu @ 2002-07-05 16:11 ` Stan Shebs 2002-07-05 16:12 ` David Edelsohn 0 siblings, 1 reply; 47+ messages in thread From: Stan Shebs @ 2002-07-05 16:11 UTC (permalink / raw) To: H. J. Lu Cc: David O'Brien, Mark Mitchell, Andreas Jaeger, gcc, Gerald Pfeifer "H. J. Lu" wrote: > > On Fri, Jul 05, 2002 at 02:46:11PM -0700, David O'Brien wrote: > > On Fri, Jul 05, 2002 at 02:35:34PM -0700, H. J. Lu wrote: > > > IMHO, keep the C++ ABI compatibility between 3.1 and 3.1.x, but break > > > between 3.1.x and 3.2, is one of the worst things anyone can do to gcc. > > > > Why? Both Andreas said that the change happening 3.1.1->3.2 will cause > > problems in upcoming OS releases. You didn't give any reasoning for your > > position. > > My position is I doubt many people really case the C++ ABI compatibility > between 3.1 and 3.1.1, at least I don't. I can even pretend 3.1 never > existed :-(. Apple is going to care a lot. Jaguar is all based on 3.1, and it's likely that some developer tool releases are going to use 3.1.1 or later, in which case it's imperative that 3.1 and 3.1.x all be binary compatible. 3.2 is a ways off still, who knows what kind of compatibility it will have in the end. It's even possible that we or somebody else will work up a patch to provide a runtime choice between 3.1 and 3.2 ABI - Apple's GCC already has terrible ugly patches to optionally emulate parts of the 2.95 ABI, but they (along with some ugly kernel hackery) make it possible for existing 0S X 10.1 drivers to "just work" on Jaguar, so they're worth the extra trouble. Stan ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 16:11 ` Stan Shebs @ 2002-07-05 16:12 ` David Edelsohn 2002-07-05 16:35 ` Stan Shebs ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: David Edelsohn @ 2002-07-05 16:12 UTC (permalink / raw) To: gcc I thought that after GCC 3.1 was released, C++ bugs were suppose to be fixed in a backward-compatible way not requiring incompatible changes in the ABI, even if that required extra work. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 16:12 ` David Edelsohn @ 2002-07-05 16:35 ` Stan Shebs 2002-07-05 22:18 ` Geoff Keating 2002-07-07 23:14 ` Mark Mitchell 2 siblings, 0 replies; 47+ messages in thread From: Stan Shebs @ 2002-07-05 16:35 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc David Edelsohn wrote: > > I thought that after GCC 3.1 was released, C++ bugs were suppose > to be fixed in a backward-compatible way not requiring incompatible > changes in the ABI, even if that required extra work. If 3.1's output is inadvertantly different from what the ABI prescribes, then either you do nothing and be incompatible with the ABI (and other compilers), or you change the compiler and make 3.2 incompatible with 3.1. The only possible extra work I can think of for this conundrum is to add a -fabi-3.1 flag that sacrifices strict ABI compliance so as to match 3.1. Stan ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 16:12 ` David Edelsohn 2002-07-05 16:35 ` Stan Shebs @ 2002-07-05 22:18 ` Geoff Keating 2002-07-07 23:14 ` Mark Mitchell 2 siblings, 0 replies; 47+ messages in thread From: Geoff Keating @ 2002-07-05 22:18 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc David Edelsohn <dje@watson.ibm.com> writes: > I thought that after GCC 3.1 was released, C++ bugs were suppose > to be fixed in a backward-compatible way not requiring incompatible > changes in the ABI, even if that required extra work. I don't believe that's possible in this case. Of the three bugs I've seen referenced, two are layout problems; there's no way to be compatible if GCC currently expects a field to be in one place and the ABI requires it to be in another, especially if the two places overlap. -- - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 16:12 ` David Edelsohn 2002-07-05 16:35 ` Stan Shebs 2002-07-05 22:18 ` Geoff Keating @ 2002-07-07 23:14 ` Mark Mitchell 2 siblings, 0 replies; 47+ messages in thread From: Mark Mitchell @ 2002-07-07 23:14 UTC (permalink / raw) To: David Edelsohn, gcc --On Friday, July 05, 2002 06:12:28 PM -0400 David Edelsohn <dje@watson.ibm.com> wrote: > I thought that after GCC 3.1 was released, C++ bugs were suppose > to be fixed in a backward-compatible way not requiring incompatible > changes in the ABI, even if that required extra work. When that's possible, that might make sense. In the cases we've run into so far, it hasn't been possible, regardless of how much work you put into it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:46 ` David O'Brien 2002-07-05 15:02 ` H. J. Lu @ 2002-07-05 15:02 ` Mark Mitchell 2002-07-06 6:28 ` Scott Robert Ladd 2002-07-06 4:56 ` Andreas Jaeger 2 siblings, 1 reply; 47+ messages in thread From: Mark Mitchell @ 2002-07-05 15:02 UTC (permalink / raw) To: obrien; +Cc: Andreas Jaeger, gcc, Gerald Pfeifer --On Friday, July 05, 2002 02:28:38 PM -0700 David O'Brien <obrien@FreeBSD.org> wrote: > On Fri, Jul 05, 2002 at 12:51:17PM -0700, Mark Mitchell wrote: >> In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible >> with respect to the C++ ABI. >> >> I can't say what that might mean as a distributor. > > I can -- MAJOR pain and difficulty. It would probably prevent FreeBSD > using GCC 3.2 in our 5.1 and later 5.x releases. That means 1-2 years > before the compiler can be upgraded for our users. > > I urge you as strongly as I can to back port (#define wrap if needed) the > changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with > GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] > and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 > and can take ABI hits right now. It's not the job of the FSF maintainers to do this. If FreeBSD wants to backport patches, for its version, that's fine. My goal, as RM, is for FSF users to be able to go from 3.1 to 3.1.1 without difficulty. (The point of the minor releases is to fix critical bugs.) We can't possibly know when we release 3.1.1 -- soon -- what changes may or not be in 3.2 -- which is still months away. I, of all people, appreciate the importance of binary compatibility in C++. There's really very little we can do, other than trying to find and fix all the problems. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* RE: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 15:02 ` Mark Mitchell @ 2002-07-06 6:28 ` Scott Robert Ladd 0 siblings, 0 replies; 47+ messages in thread From: Scott Robert Ladd @ 2002-07-06 6:28 UTC (permalink / raw) To: gcc Perhaps I'm a bit out-of-line by dropping into this debate, but I see some nasty trends that are "bad" for the entire free software movement. MM> Because our goal is to produce minor releases MM> that fix critical bugs. How does the above statement play with something Mark Mitchell said in an earlier post: MM> Yes, the implementation had some bugs. It was MM> also the case that the ABI specification had some MM> bugs/omissions/unclarities. If the ABI specification is buggy, shouldn't such "bugs" be fixed in an interim release, i.e., 3.1.1? The ABI is fundamental, and if changes must be made, sooner is far better than later. MM> It's not the job of the FSF maintainers to do this. I submit that this may be true in an absolute sense, but such an attitude fails to recognize the importance of gcc. gcc is the foundation of free and open software; if that foundation keeps shifting, it increases risk and stress for those building upon it. MM> Adding in new, not nearly as well-tested ABI changes, MM> one week for a release is simply not going to happen. The perhaps the release schedule is unrealistic? ..Scott (Who'd love to help with gcc if he could figure out where to stick his nose...) Scott Robert Ladd Coyote Gulch Productions, http://www.coyotegulch.com No ads -- just very free (and somewhat unusual) code. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-05 14:46 ` David O'Brien 2002-07-05 15:02 ` H. J. Lu 2002-07-05 15:02 ` Mark Mitchell @ 2002-07-06 4:56 ` Andreas Jaeger 2002-07-06 6:44 ` Gerald Pfeifer 2 siblings, 1 reply; 47+ messages in thread From: Andreas Jaeger @ 2002-07-06 4:56 UTC (permalink / raw) To: obrien; +Cc: Mark Mitchell, gcc, Gerald Pfeifer "David O'Brien" <obrien@FreeBSD.org> writes: > On Fri, Jul 05, 2002 at 12:51:17PM -0700, Mark Mitchell wrote: >> In any case, GCC 3.1 and GCC 3.2 will not be 100% binary compatible >> with respect to the C++ ABI. >> >> I can't say what that might mean as a distributor. > > I can -- MAJOR pain and difficulty. It would probably prevent FreeBSD > using GCC 3.2 in our 5.1 and later 5.x releases. That means 1-2 years > before the compiler can be upgraded for our users. The same for most Linux distributors if they go with 3.1.x - and I know that some will go, including SuSE. > > I urge you as strongly as I can to back port (#define wrap if needed) the > changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with > GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] > and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 > and can take ABI hits right now. The same applies for SuSE and possible also other distributors, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 4:56 ` Andreas Jaeger @ 2002-07-06 6:44 ` Gerald Pfeifer 2002-07-06 7:35 ` Andreas Jaeger 2002-07-06 11:44 ` David O'Brien 0 siblings, 2 replies; 47+ messages in thread From: Gerald Pfeifer @ 2002-07-06 6:44 UTC (permalink / raw) To: Andreas Jaeger, David O'Brien; +Cc: Mark Mitchell, gcc On Sat, 6 Jul 2002, Andreas Jaeger wrote: >> I urge you as strongly as I can to back port (#define wrap if needed) the >> changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with >> GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] >> and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 >> and can take ABI hits right now. > The same applies for SuSE and possible also other distributors, What's the cut-off date where you (Andreas, David,...) would need to have a release of GCC with such a C++ ABI change? There are strong arguments not to make this change for 3.1.1 which is due quite soon, but that doesn't prevent us from making another release shortly thereafter, for example. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 6:44 ` Gerald Pfeifer @ 2002-07-06 7:35 ` Andreas Jaeger 2002-07-06 11:44 ` David O'Brien 1 sibling, 0 replies; 47+ messages in thread From: Andreas Jaeger @ 2002-07-06 7:35 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: David O'Brien, Mark Mitchell, gcc Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes: > On Sat, 6 Jul 2002, Andreas Jaeger wrote: >>> I urge you as strongly as I can to back port (#define wrap if needed) the >>> changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with >>> GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] >>> and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 >>> and can take ABI hits right now. >> The same applies for SuSE and possible also other distributors, > > What's the cut-off date where you (Andreas, David,...) would need to > have a release of GCC with such a C++ ABI change? If we get something still in July, it would be perfect. If it comes out later, it might be ok but then I would need some release date to plan for it. September will be too late. > There are strong arguments not to make this change for 3.1.1 which is > due quite soon, but that doesn't prevent us from making another release > shortly thereafter, for example. I agree with this reasoning. Thanks for considering these issues, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 6:44 ` Gerald Pfeifer 2002-07-06 7:35 ` Andreas Jaeger @ 2002-07-06 11:44 ` David O'Brien 1 sibling, 0 replies; 47+ messages in thread From: David O'Brien @ 2002-07-06 11:44 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Andreas Jaeger, Mark Mitchell, gcc On Sat, Jul 06, 2002 at 03:18:00PM +0200, Gerald Pfeifer wrote: > On Sat, 6 Jul 2002, Andreas Jaeger wrote: > >> I urge you as strongly as I can to back port (#define wrap if needed) the > >> changes so that GCC 3.1.1 can be built to be 100% C++ ABI compatible with > >> GCC 3.2. FreeBSD can much more easily accept breakage between 3.1[.0] > >> and 3.1.1, than between 3.1.1 and 3.2[.0] as we are still developing 5.0 > >> and can take ABI hits right now. > > The same applies for SuSE and possible also other distributors, > > What's the cut-off date where you (Andreas, David,...) would need to > have a release of GCC with such a C++ ABI change? FreeBSD would need a release with updated C++ ABI by Sept 1, 2002 at the very latest. That also assumes that there aren't major regressions in said release. Example of things that we couldn't have happen with a Sept 1st compiler are things like: * the "#pragma weak" bug that caused stock XFree86 4.2.0 to not compile * the reload bug that could only be avoided by compiling XFree86 with -O0 * that requested alignment isn't obeyed and thus boot blocks can't be made small enough * that with every GCC upgrade we have to tweak our in-line asm statements * anything that would cause 20% of our 8000 3rd-party packages (The Ports Collection) to no longer build. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-04 9:55 C++ binary compatibility between GCC 3.1 and GCC 3.2? Andreas Jaeger 2002-07-04 10:23 ` H. J. Lu 2002-07-05 14:17 ` Mark Mitchell @ 2002-07-05 22:35 ` David Edelsohn 2002-07-06 5:40 ` Joseph S. Myers 3 siblings, 0 replies; 47+ messages in thread From: David Edelsohn @ 2002-07-05 22:35 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc I have raised this concern to the GCC Steering Committee as well. It is unclear how much flexibility is available this close to the GCC 3.1.1 announced release date. Also, the U.S. Independence Day holiday weekend may delay responses from both U.S.-based GCC SC members and U.S.-based GCC developers. Hopefully the feedback and suggestions from this discussion can help the GCC SC reach a consensus. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-04 9:55 C++ binary compatibility between GCC 3.1 and GCC 3.2? Andreas Jaeger ` (2 preceding siblings ...) 2002-07-05 22:35 ` David Edelsohn @ 2002-07-06 5:40 ` Joseph S. Myers 2002-07-06 6:40 ` Gabriel Dos Reis 3 siblings, 1 reply; 47+ messages in thread From: Joseph S. Myers @ 2002-07-06 5:40 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc On Thu, 4 Jul 2002, Andreas Jaeger wrote: > What will this mean for distributions and for production usage of GCC > 3.1? I fear this means that folks cannot easily upgrade from GCC 3.1 > to GCC 3.2 since C++ is incompatible and all C++ libraries that are > needed for development need to be relinked. Where does libstdc++ fit into this? Is libstdc++ yet ready to be binary compatible between successive major releases? If not, how useful is binary compatibility of the underlying C++ ABI? -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 5:40 ` Joseph S. Myers @ 2002-07-06 6:40 ` Gabriel Dos Reis 2002-07-06 7:49 ` Andreas Jaeger 0 siblings, 1 reply; 47+ messages in thread From: Gabriel Dos Reis @ 2002-07-06 6:40 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Andreas Jaeger, gcc "Joseph S. Myers" <jsm28@cam.ac.uk> writes: | On Thu, 4 Jul 2002, Andreas Jaeger wrote: | | > What will this mean for distributions and for production usage of GCC | > 3.1? I fear this means that folks cannot easily upgrade from GCC 3.1 | > to GCC 3.2 since C++ is incompatible and all C++ libraries that are | > needed for development need to be relinked. | | Where does libstdc++ fit into this? The library is not covered by the ABI requirement; but we try hard to retain ABI compatibility. | Is libstdc++ yet ready to be binary | compatible between successive major releases? No, we're currently far from that -- but we're striving for that goal. | If not, how useful is | binary compatibility of the underlying C++ ABI? People have been using third-party libary in place of libstdc++-v3. Also, most of codes in libstc++-v3 are in headers (template definitions) so the issue is less sensitive than with the compiler. -- Gaby ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? 2002-07-06 6:40 ` Gabriel Dos Reis @ 2002-07-06 7:49 ` Andreas Jaeger 0 siblings, 0 replies; 47+ messages in thread From: Andreas Jaeger @ 2002-07-06 7:49 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Joseph S. Myers, gcc Gabriel Dos Reis <gdr@codesourcery.com> writes: > "Joseph S. Myers" <jsm28@cam.ac.uk> writes: > > | On Thu, 4 Jul 2002, Andreas Jaeger wrote: > | > | > What will this mean for distributions and for production usage of GCC > | > 3.1? I fear this means that folks cannot easily upgrade from GCC 3.1 > | > to GCC 3.2 since C++ is incompatible and all C++ libraries that are > | > needed for development need to be relinked. > | > | Where does libstdc++ fit into this? > > The library is not covered by the ABI requirement; but we try hard to > retain ABI compatibility. With symbol versioning (that is implemented in libstdc++) it shouldn't be a problem to retain ABI compatibility as long as the C++ ABI is stable. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2002-07-08 2:10 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3900A36C.18989ED4@apple.com> 2000-04-21 17:17 ` [patch] beginnings of the macro rewrite Horst von Brand 2000-04-22 10:33 ` Zack Weinberg 2000-04-22 20:13 ` Marc Espie 2000-04-22 20:20 ` Neil Booth 2000-04-24 8:57 ` Michael Meissner 2000-04-24 17:54 ` Russ Allbery 2000-04-27 15:54 ` Philipp Thomas 2000-04-27 17:32 ` Joe Buck 2000-04-24 23:38 ` Martin Kahlert 2000-04-23 4:04 Richard Kenner 2002-07-04 9:55 C++ binary compatibility between GCC 3.1 and GCC 3.2? Andreas Jaeger 2002-07-04 10:23 ` H. J. Lu 2002-07-05 14:17 ` Mark Mitchell 2002-07-05 14:22 ` Andreas Jaeger 2002-07-05 14:28 ` Mark Mitchell 2002-07-05 14:53 ` David O'Brien 2002-07-05 15:08 ` Mark Mitchell 2002-07-06 5:34 ` Andreas Jaeger 2002-07-06 6:40 ` Gabriel Dos Reis 2002-07-06 6:40 ` Jakub Jelinek 2002-07-06 7:20 ` Gabriel Dos Reis 2002-07-06 7:53 ` Andreas Jaeger 2002-07-06 8:54 ` Gabriel Dos Reis 2002-07-06 11:04 ` Daniel Jacobowitz 2002-07-06 7:42 ` Andreas Jaeger 2002-07-06 11:08 ` Jeff Law 2002-07-06 11:10 ` Gwenole Beauchesne 2002-07-06 6:19 ` Daniel Egger 2002-07-05 14:46 ` David O'Brien 2002-07-05 15:02 ` H. J. Lu 2002-07-05 15:12 ` David O'Brien 2002-07-05 15:20 ` H. J. Lu 2002-07-05 16:11 ` Stan Shebs 2002-07-05 16:12 ` David Edelsohn 2002-07-05 16:35 ` Stan Shebs 2002-07-05 22:18 ` Geoff Keating 2002-07-07 23:14 ` Mark Mitchell 2002-07-05 15:02 ` Mark Mitchell 2002-07-06 6:28 ` Scott Robert Ladd 2002-07-06 4:56 ` Andreas Jaeger 2002-07-06 6:44 ` Gerald Pfeifer 2002-07-06 7:35 ` Andreas Jaeger 2002-07-06 11:44 ` David O'Brien 2002-07-05 22:35 ` David Edelsohn 2002-07-06 5:40 ` Joseph S. Myers 2002-07-06 6:40 ` Gabriel Dos Reis 2002-07-06 7:49 ` Andreas Jaeger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).