Re: [patch] beginnings of the macro rewrite

Re: [patch] beginnings of the macro rewrite

[Horst von Brand]

[-- 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

Re: [patch] beginnings of the macro rewrite

[Zack Weinberg]

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

Re: [patch] beginnings of the macro rewrite

[Marc Espie]

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.

Re: [patch] beginnings of the macro rewrite

[Neil Booth]

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.

Re: [patch] beginnings of the macro rewrite

[Michael Meissner]

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

Re: [patch] beginnings of the macro rewrite

[Russ Allbery]

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/ >

Re: [patch] beginnings of the macro rewrite

[Philipp Thomas]

* 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

Re: [patch] beginnings of the macro rewrite

[Joe Buck]

> 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.

Re: [patch] beginnings of the macro rewrite

[Martin Kahlert]

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.

Re: [patch] beginnings of the macro rewrite

[Richard Kenner]

    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.

C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[H. J. Lu]

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.

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Mark Mitchell]

> 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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Mark Mitchell]

>> 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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[David O'Brien]

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)

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Mark Mitchell]

--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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Gabriel Dos Reis]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Jakub Jelinek]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Gabriel Dos Reis]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Gabriel Dos Reis]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Daniel Jacobowitz]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Jeff Law]

 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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Gwenole Beauchesne]

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.

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Daniel Egger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[David O'Brien]

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)

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[H. J. Lu]

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.

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[David O'Brien]

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)

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[H. J. Lu]

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.

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Stan Shebs]

"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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[David Edelsohn]

	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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Stan Shebs]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Geoff Keating]

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>

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Mark Mitchell]

--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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Mark Mitchell]

--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

RE: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Scott Robert Ladd]

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.

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

"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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Gerald Pfeifer]

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/

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[David O'Brien]

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.

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[David Edelsohn]

	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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Joseph S. Myers]

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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Gabriel Dos Reis]

"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

Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Andreas Jaeger]

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