This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: ARM va_list


On Mon, 2009-01-19 at 12:03 -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 19, 2009 at 01:10:57AM +0000, Paul Brook wrote:
> > On Monday 19 January 2009, Mark Mitchell wrote:
> > > Joseph S. Myers wrote:
> > > > Did we reach any actual conclusion as to whether this should go in 4.4 or
> > > > not?
> > >
> > > I think that Paul's opinion of record at present is that we should wait
> > > for some other time when we are breaking ABI compatibility.
> > 
> > Correct, based on the theory that compatibility with previous gcc is more 
> > important than compatibility with third party toolchains.
> > 
> > I'm willing to be outvoted if other people feel differently.
> 
> Since this doesn't affect the ABI of any library included in GCC, I
> think we should fix it sooner rather than later; there will be
> convenient times to break the libstdc++ ABI, but I hope there won't be
> a convenient time to break the C++ ABI.
> 

My understanding is that the next C++ standard may well force such a
breakage...

However, that's a side point.

There are three cases to consider:

1) Bare metal -- essentially everything is re-built with the compiler of
choice.  In this case I think conformance with the ABI is preferable --
there really is no legacy to deal with.

2) Platforms where the primary compiler is not GCC.  A key case here
would be SymbianOS.  In that case, conformance with the primary compiler
needs to be considered.  This argues strongly in favour of the change.

3) Platforms where GCC is the primary compiler, such as linux.  This
case argues more strongly for maintaining backwards compatibility, but
not, I think, conclusively: this is a bug just like may other bugs that
we fix in GCC.

On balance I think it would be useful to maintain the backwards
compatibility for Linux, but essential to gain ABI compatibility for
SymbianOS.  If both of those goals cannot be satisfied simultaneously,
then I think we need to go with ABI conformance: in the end, that is the
the rules by which we are claiming to adhere.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]