This is the mail archive of the
mailing list for the GCC project.
Re: Removal of V2 code
>>>>> "Geoff" == Geoff Keating <email@example.com> writes:
Geoff> The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't
Geoff> work yet with V3; I don't believe anyone, certainly not at
Geoff> Red Hat, will be able to fix this until next month; we
Geoff> don't have time.
Put simply, I don't think that is an issue for the FSF release. None
of these platforms are on primary release criteria list. If Red Hat
has customers that need support for these platforms, then Red Hat will
presumably provide implement support for V3.
Geoff> Do HPUX, IRIX, BeOS work?
I don't know about HPUX or BeOS. IRIX works.
Geoff> Does SunOS (not Solaris) work? I think we still have SunOS
I don't know about SunOS either. Kaveh?
I don't think Red Hat's customer list is relevant, except as some sort
of barometer of who's out there. But, we already have release
criteria, and I believe that V3 works on all of those platforms except
for HPUX (for which we have no target triplet in the critera; I wonder
what version we're talking about here) and AIX (being worked on,
expected to work soon).
Doing the porting work really isn't hard and it's getting easier the
more platforms we do. Any ELF platform with a reasonably compliant C
library should be a snap. I don't know how conformant newlib is; it
might be that you have to tweak some configuration bits to make that
work. It's a day or two's work, a week tops. And once it works with
newlib somewhere, it will probably work everywhere; the amount of
target-specific code in V3 is tiny, and there are generic C versions
Geoff> Such a change will make it difficult for us to merge
Geoff> patches back into the FSF sources, because we would not be
Geoff> able to test them.
I should think that you could find a stock i686-pc-linux-gnu system to
test platform-independent changes on. :-) And for most chips (MIPS,
PowerPC, etc.) I bet you have non-embedded alternatives to test
back-end changes on. There may be rare chips for which this is not
possible, but there is likely either no C++ support for those chips at
all in the FSF tree, or there is a non-embedded target for which you
simply do not have access to appropriate hardware. In that case, I'm
sure that either someone will provide you access to the hardware, test
your patch themselves, or that you can go ahead and check it in, and
let the people with the right hardware check out what happens.
Any changes you make in your internal tree need to be tested in the
public tree, using the same configuration that everyone else uses,
before you check them in anyhow. It would be wrong to test a C++
patch with V2 and check it in without testing it with V3, even if V2
were still in the tree, since V3 is whatever everyone else is using.
99% of all changes coming from Red Hat are to code where there are not
likely to be any merge issues depending on whether V2 or V3 is in use.
It's going to be `cvs diff' and `patch' independent of the V2 vs. V3
issues. That's the procedure for testing a patch from your internal
tree anyhow; how does the absence of V2 in the FSF sources make this
Is there some deeper technical issue I'm not seeing?
Geoff> Already you can see this effect; you will notice that the
Geoff> automated tester is no longer testing C++ because the
Geoff> platform it tests with is not supported by libstdc++-v3.
The regression tester is something you (quite generously!) decided to
set up. It would be great if someone could port V3 to that platform.
You could also choose a different target, which would allow us to
continue getting the regression-testing reports for C++, at the
expense of testing a different chip.
Geoff> I believe this schedule is far too quick. We have only had
Geoff> libstdc++-v3 as the default for a few weeks, there are
Geoff> known problems, these problems will take some time to fix.
Geoff> I would wait 6 months and ask again.
You make it sound as though the switch was a surprise. :-)
The switch to V3, and to the new ABI, and the removal of the previous
versions of these things was announced as long as a year ago, and both
V3 and the new ABI have been in the tree for many months.
If people who build tools based on or around G++ haven't prepared
themselves for this transition, that was probably a mistake.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com