* Re: Removal of V2 code
@ 2000-11-20 8:55 Kaveh R. Ghazi
2000-11-20 9:46 ` sun/os as release candidate was: " Robert Lipe
2000-11-20 9:47 ` law
0 siblings, 2 replies; 37+ messages in thread
From: Kaveh R. Ghazi @ 2000-11-20 8:55 UTC (permalink / raw)
To: geoffk, mark; +Cc: gcc
> From: Mark Mitchell <mark@codesourcery.com>
>
> Geoff> Does SunOS (not Solaris) work? I think we still have SunOS
> Geoff> customers.
>
> I don't know about SunOS either. Kaveh?
I mentioned this to Mark offline, but it deserves wider attention.
the SunOS box I had access to died and its sysadmin decided not to
revive it. Therefore I cannot assist in testing or V3 porting to
SunOS.
I've felt SunOS a worthy second tier candidate for these reasons:
Tests K&R stage1 support
Tests fixincludes thoroughly
Tests SJLJ exceptions
Tests other various missing OS feature handling in gcc
I hope someone will volunteer to champion SunOS in lieu of me.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions
^ permalink raw reply [flat|nested] 37+ messages in thread
* sun/os as release candidate was: Removal of V2 code
2000-11-20 8:55 Removal of V2 code Kaveh R. Ghazi
@ 2000-11-20 9:46 ` Robert Lipe
2000-11-20 17:59 ` Gerald Pfeifer
2000-11-20 9:47 ` law
1 sibling, 1 reply; 37+ messages in thread
From: Robert Lipe @ 2000-11-20 9:46 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc
Kaveh R. Ghazi wrote:
> the SunOS box I had access to died
While I'm sorry for your loss, there are ways to help coverage even in
the absence of such a system.
> I've felt SunOS a worthy second tier candidate for these reasons:
>
> Tests K&R stage1 support
Many modern compilers have flags to dumb them down to K&R mode. Perhaps
this could be accomplished by doing bootstraps with a compiler in such a
mode. I suspect that "gcc -ansi" is probably not the best test, but it
might suffice. Some vendor compiler might be a better test.
Someone that cares about K&R could step up to the plate to add a cron
job to do a nightly (or whatever) build on such a system.
Does anyone other than HP even still provide a K&R-only compiler? If
so, since there are binary kits of GCC available for that target, has
the time come for us to relax the K&R restriction for bootstrapping GCC
completely?
> Tests SJLJ exceptions
OpenServer in COFF mode uses SJLJ exceptions. (It's one reason I'm
strongly considering yanking COFF mode; sjlj and dwarf-1 problems
are apparently of decreasing strategic value to GCC and they break
frequently.) This could be exercised somewhat by one of the nightly
build processes by adding another pass with '-fsjlj-exceptions' or even
doing a bootstrap by adding it to BOOT_CLFAGS. This could give us
coverage on a system that doesn't _need_ SJLJ.
> Tests fixincludes thoroughly
> Tests other various missing OS feature handling in gcc
Those represent holes. OTOH, maybe they represent holes that are of
only of value on such an archaic target...I mean, does any actively
maintained host/target still really spell "memcpy" only as "bcopy"?
RJL
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 8:55 Removal of V2 code Kaveh R. Ghazi
2000-11-20 9:46 ` sun/os as release candidate was: " Robert Lipe
@ 2000-11-20 9:47 ` law
1 sibling, 0 replies; 37+ messages in thread
From: law @ 2000-11-20 9:47 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: geoffk, mark, gcc
In message < 200011201655.LAA09289@caip.rutgers.edu >you write:
> I mentioned this to Mark offline, but it deserves wider attention.
> the SunOS box I had access to died and its sysadmin decided not to
> revive it. Therefore I cannot assist in testing or V3 porting to
> SunOS.
>
> I've felt SunOS a worthy second tier candidate for these reasons:
>
> Tests K&R stage1 support
> Tests fixincludes thoroughly
> Tests SJLJ exceptions
FWIW, if we can get the PA/hpux bits in libstdc++-v3 up and running, then
the PA port can test those issues pretty well :-)
jeff
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: sun/os as release candidate was: Removal of V2 code
2000-11-20 9:46 ` sun/os as release candidate was: " Robert Lipe
@ 2000-11-20 17:59 ` Gerald Pfeifer
0 siblings, 0 replies; 37+ messages in thread
From: Gerald Pfeifer @ 2000-11-20 17:59 UTC (permalink / raw)
To: Robert Lipe; +Cc: Kaveh R. Ghazi, gcc
On Mon, 20 Nov 2000, Robert Lipe wrote:
> Someone that cares about K&R could step up to the plate to add a cron
> job to do a nightly (or whatever) build on such a system.
Exactly. And if there's none left who cares about K&R, well, than at some
point in the future we should decide that this requirement will go away.
> Does anyone other than HP even still provide a K&R-only compiler? If
> so, since there are binary kits of GCC available for that target, has
> the time come for us to relax the K&R restriction for bootstrapping GCC
> completely?
Personally, I wouldn't mind very much... (But we shouldn't do this
lightly and really check that no platforms in use break.)
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 16:08 ` Tom Tromey
@ 2000-11-21 21:41 ` Mark Mitchell
0 siblings, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-21 21:41 UTC (permalink / raw)
To: tromey; +Cc: gcc
>>>>> "Tom" == Tom Tromey <tromey@cygnus.com> writes:
Mark> I believe that in general the details of SC discussions are
Mark> considered confidential in order to encourage frank
Mark> exchanges of ideas among the SC members. I could be wrong
Mark> about that, but that's how I've always treated other
Mark> people's SC postings. If I'm right, that would make
Mark> releasing any such archives inappropriate.
Tom> What is it about release schedules that makes it important to
Tom> discuss them secretly?
Nothing in particular.
I was just trying to answer the question as to why there are no mail
archives and such.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 15:06 ` Mark Mitchell
@ 2000-11-21 16:08 ` Tom Tromey
2000-11-21 21:41 ` Mark Mitchell
0 siblings, 1 reply; 37+ messages in thread
From: Tom Tromey @ 2000-11-21 16:08 UTC (permalink / raw)
To: Mark Mitchell; +Cc: GCC Hackers
Mark> I believe that in general the details of SC discussions are
Mark> considered confidential in order to encourage frank exchanges of
Mark> ideas among the SC members. I could be wrong about that, but
Mark> that's how I've always treated other people's SC postings. If
Mark> I'm right, that would make releasing any such archives
Mark> inappropriate.
What is it about release schedules that makes it important to discuss
them secretly? I think having a debate about whether to release
2.95.3 should happen in public. In fact, the debate will probably
happen anyway, whether the SC wants it or not. I know we've discussed
it several times on the Java list (mostly in terms of "I don't know if
there will be one, since it is only discussed in secret").
Tom
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 14:14 ` Geoff Keating
@ 2000-11-21 15:06 ` Mark Mitchell
2000-11-21 16:08 ` Tom Tromey
0 siblings, 1 reply; 37+ messages in thread
From: Mark Mitchell @ 2000-11-21 15:06 UTC (permalink / raw)
To: geoffk; +Cc: gcc
>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:
Geoff> Are there records of such debates anywhere? Minutes of
Geoff> meetings, mailing list archives, etc.?
Not to my knowledge.
I believe that in general the details of SC discussions are considered
confidential in order to encourage frank exchanges of ideas among the
SC members. I could be wrong about that, but that's how I've always
treated other people's SC postings. If I'm right, that would make
releasing any such archives inappropriate.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 14:58 ` Mark Mitchell
@ 2000-11-21 14:14 ` Geoff Keating
2000-11-21 15:06 ` Mark Mitchell
0 siblings, 1 reply; 37+ messages in thread
From: Geoff Keating @ 2000-11-21 14:14 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
Mark Mitchell <mark@codesourcery.com> writes:
> >>>>> "Hartmut" == Hartmut Schirmer <hartmut.schirmer@arcormail.de> writes:
>
> Hartmut> On Mon, 20 Nov 2000, Mark Mitchell wrote:
> >> The attitude at the time the release criteria were put together
> >> was that you could always use GCC 2.95 if you wanted an ABI
> >> compatible with GCC 2.95. :-)
>
> Hartmut> But we´re waiting for gcc 2.95.3 for more than a year now
> Hartmut> :((
>
> There aren't currently any plans for such a release, but the Steering
> Committe is debating such a release even as we speak.
Are there records of such debates anywhere? Minutes of meetings,
mailing list archives, etc.?
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 12:37 ` Geoff Keating
@ 2000-11-21 12:47 ` Mark Mitchell
0 siblings, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-21 12:47 UTC (permalink / raw)
To: geoffk, geoffk; +Cc: gcc, libstdc++
>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:
>> Cc: gcc@gcc.gnu.org, libstdc++@sources.redhat.com From: Mark
>> Mitchell <mark@codesourcery.com> Date: Tue, 21 Nov 2000
>> 10:56:13 -0800
>> Geoff --
>>
>> Thanks for the script. It worked great.
>>
>> The rumors of V2 not working with newlib were greatly
>> exaggerated.
Geoff> Great! (I assume you mean V3). It seems to have changed
Yes, sorry, for the confusion.
Geoff> since I looked at it last.
I think this may be because the V3 folks put some stubs for threading
primitives in place that will provide a non thread-safe implementation
on all platforms.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 12:20 ` Benjamin Kosnik
@ 2000-11-21 12:45 ` Mark Mitchell
0 siblings, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-21 12:45 UTC (permalink / raw)
To: bkoz; +Cc: geoffk, geoffk, gcc, libstdc++
>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
>> The rumors of V2 not working with newlib were greatly
>> exaggerated.
Benjamin> Err. I think you mean the rumors of V3 working with
Benjamin> newlib have been greatly exaggerated.
Right.
>> Even without this change, however, the configuration completed,
>> built the library, and mostly worked.
Benjamin> ... this has been my experience as well. Nice to see it
Benjamin> confirmed.
Yup. Nice work setting this stuff up.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 10:56 ` Mark Mitchell
2000-11-21 12:20 ` Benjamin Kosnik
@ 2000-11-21 12:37 ` Geoff Keating
2000-11-21 12:47 ` Mark Mitchell
1 sibling, 1 reply; 37+ messages in thread
From: Geoff Keating @ 2000-11-21 12:37 UTC (permalink / raw)
To: mark; +Cc: gcc, libstdc++
> Cc: gcc@gcc.gnu.org, libstdc++@sources.redhat.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Tue, 21 Nov 2000 10:56:13 -0800
> Geoff --
>
> Thanks for the script. It worked great.
>
> The rumors of V2 not working with newlib were greatly exaggerated.
Great! (I assume you mean V3). It seems to have changed since I
looked at it last.
Now the problem is that V3 doesn't cross-configure from Solaris. I get:
updating cache ../config.cache
/sloth/delay/tbox/cvs-gcc/egcs/libstdc++-v3/configure: test: argument expected
and the configuration stops. This is just the usual breakage, though,
and probably easily fixed, as compared to the earlier situation where
it looked like lots of porting would be required.
So, go for it!
> The code in question looks like it calls `_fcntl'; I don't know why
> the linker reports that as `fcntl'. I don't understand what's causing
> that, but it's clear that it has nothing to do with V3. I suspect a
> newlib configury issue. Geoff, would you mind tracking this down?
I'll look at it.
Thank you very much for your work!
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 10:56 ` Mark Mitchell
@ 2000-11-21 12:20 ` Benjamin Kosnik
2000-11-21 12:45 ` Mark Mitchell
2000-11-21 12:37 ` Geoff Keating
1 sibling, 1 reply; 37+ messages in thread
From: Benjamin Kosnik @ 2000-11-21 12:20 UTC (permalink / raw)
To: Mark Mitchell; +Cc: geoffk, geoffk, gcc, libstdc++
> The rumors of V2 not working with newlib were greatly exaggerated.
Err. I think you mean the rumors of V3 working with newlib have been
greatly exaggerated. As a matter of fact, it's been working since about Feb.
I did a cross x86-x-powerpc-elf this Sunday, as a matter of fact, and it
worked well.
> I made absolutely no changes to the source code or configury bits.
...as none should be needed.
> There was also one configury oddity in the V3 directory:
>
> /nfs/gandalf/u2/mitchell/dev/powerpc-test/cvs-objs/gcc/egcs/libstdc++-v3/configure: test: =: unary operator expected
>
> This comes from:
>
> AC_DEFUN(AC_LC_MESSAGES,
> [if test $ac_cv_header_locale_h = yes; then
> AC_CACHE_CHECK([for LC_MESSAGES], ac_cv_val_LC_MESSAGES,
>
> when $ac_cv_header_locale_h is not yet set. I think that the V3
> configury bits should check for <locale.h> first. Would a V3 person
> please confirm that, and make the necessary change?
I'll fix this.
> Even without this change, however, the configuration completed,
> built the library, and mostly worked.
... this has been my experience as well. Nice to see it confirmed.
-benjamin
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 22:12 ` Geoff Keating
2000-11-19 22:33 ` Mark Mitchell
2000-11-20 1:07 ` Mark Mitchell
@ 2000-11-21 10:56 ` Mark Mitchell
2000-11-21 12:20 ` Benjamin Kosnik
2000-11-21 12:37 ` Geoff Keating
2 siblings, 2 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-21 10:56 UTC (permalink / raw)
To: geoffk, geoffk; +Cc: gcc, libstdc++
Geoff --
Thanks for the script. It worked great.
The rumors of V2 not working with newlib were greatly exaggerated.
I made absolutely no changes to the source code or configury bits.
Everything built, and most C++ tests passed.
Looking at the C++ tests, there were 40 unexpected failures
(relative to the 3 we see on GNU/Linux). I randomly sampled 5 of the
37 new failures; all of them had the following problem:
/nfs/gandalf/u2/mitchell/dev/powerpc-test/objs/lib/gcc-lib/powerpc-eabisim/2.97/../../../../powerpc-eabisim/lib/libc.a(fdopen.o): In function `_fdopen_r':
/nfs/gandalf/u2/mitchell/dev/powerpc-test/src-objs/newlib/libc/stdio/fdopen.c:67: undefined reference to `fcntl'
The code in question looks like it calls `_fcntl'; I don't know why
the linker reports that as `fcntl'. I don't understand what's causing
that, but it's clear that it has nothing to do with V3. I suspect a
newlib configury issue. Geoff, would you mind tracking this down?
It is possible that there will be runtime issues involving I/O
streams once the `fdopen' issue is resolved; I have no way of knowing
at this time.
There was also one configury oddity in the V3 directory:
/nfs/gandalf/u2/mitchell/dev/powerpc-test/cvs-objs/gcc/egcs/libstdc++-v3/configure: test: =: unary operator expected
This comes from:
AC_DEFUN(AC_LC_MESSAGES,
[if test $ac_cv_header_locale_h = yes; then
AC_CACHE_CHECK([for LC_MESSAGES], ac_cv_val_LC_MESSAGES,
when $ac_cv_header_locale_h is not yet set. I think that the V3
configury bits should check for <locale.h> first. Would a V3 person
please confirm that, and make the necessary change?
Even without this change, however, the configuration completed,
built the library, and mostly worked.
The Steering Committee has pretty much forbidden me from spending
more time working on getting V3 going with newlib. However, I think
it's clear that a volunteer could finish the job with minimal effort.
The first step doesn't even involve understanding anything about V3 --
just figure out what's going on with fcntl.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-21 6:38 ` Franz Sirl
@ 2000-11-21 7:26 ` Daniel Berlin
0 siblings, 0 replies; 37+ messages in thread
From: Daniel Berlin @ 2000-11-21 7:26 UTC (permalink / raw)
To: Franz Sirl; +Cc: Mark Mitchell, Geoff Keating, gcc
> BTW, shouldn't c++filt now default to the V3 mangling style too?
No. It shoudl dfault to auto, which is what it does now.
It should, however, detect V3 mangling style automatically, using the _Z
prefix.
It's a 10 minute job if someone wants to do it.
>
> Franz.
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 2:54 ` Franz Sirl
@ 2000-11-21 6:38 ` Franz Sirl
2000-11-21 7:26 ` Daniel Berlin
0 siblings, 1 reply; 37+ messages in thread
From: Franz Sirl @ 2000-11-21 6:38 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Geoff Keating, gcc
At 11:54 20.11.00, Franz Sirl wrote:
>At 02:10 20.11.00, Geoff Keating wrote:
>>Mark Mitchell <mark@codesourcery.com> writes:
>>
>> > I plan on doing a `cvs remove' on the V2 sources, and removing the
>> > configury bits for V2 at the end of next week as things seem to be
>> > settling OK with V3. (There are still some AIX issues with V3, but
>> > they seem to be well on the path to resolution.)
>> >
>> > If you have objections to this plan (i.e., you need the V2 sources to
>> > continue your work), you should:
>> >
>> > - Try hard to get V3 working on your platform.
>> >
>> > - Complain to me. Explain why you can't switch to V3, and what
>> > you need in order to make that happen.
>> >
>> > We can keep V2 in the tree for a bit longer, if we need to, but you'll
>> > have to come up with a good reason... :-)
>>
>>The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with
>>V3; I
>>don't believe anyone, certainly not at Red Hat, will be able to fix
>>this until next month; we don't have time.
>
>Well, not only the embedded stuff is non-functional, powerpc-linux-gnu is
>unusable with libstdc++-v3 too (see my posted testsuite results). I
>couldn't do too much debugging yet, but it seems most (if not all) of the
>testcases crash during constructor handling in glibc's malloc/free code.
Replying to my own message, here is a backtrace of what I get as a fail in
all cases I looked into so far, this is with todays CVS:
[fsirl@entropy:~/obj/gccm/gcc/testsuite]$
LD_LIBRARY_PATH=~/obj/gccm/ppc-redhat-linux/libstdc++-v3/src/.libs/ gdb
./g++-pt-ttp9-C
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-redhat-linux"...
(gdb) r
Starting program: /home/fsirl/obj/gccm/gcc/testsuite/./g++-pt-ttp9-C
Program received signal SIGSEGV, Segmentation fault.
0xfe3893c in chunk_free () at /usr/include/stdlib.h:269
269 return __strtold_internal (__nptr, __endptr, 0);
Current language: auto; currently c++
(gdb) bt full
#0 0xfe3893c in chunk_free () at /usr/include/stdlib.h:269
__alloc1 = (allocator<char> &) @0x10010a08: {<No data fields>}
__b = (istreambuf_iterator<char,std::char_traits<char> > &)
@0x2c030001: Cannot access memory at address 0x2c030001
(gdb) bt
#0 0xfe3893c in chunk_free () at /usr/include/stdlib.h:269
#1 0xfe388ec in free () at /usr/include/stdlib.h:269
#2 0xffa67b4 in _ZNSs4_Rep10_M_destroyERKSaIcE (this=0x2c030001,
__a=@0xffefa08)
at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/stl_alloc.h:131
#3 0xff98298 in _ZNSt6locale7classicEv () at
/home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/basic_string.h:178
#4 0xffadbbc in _ZNSt13basic_filebufIcSt11char_traitsIcEEC1Ev (this=0xffef604)
at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/localefwd.h:311
#5 0xff8fdc0 in __static_initialization_and_destruction_0
(__initialize_p=268503580, __priority=268368392)
at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/locale_facets.h:35
#6 0xff90070 in _GLOBAL_.I._ZSt11__cfileinit () at
/home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/std_fstream.h:96
#7 0xff8d7a4 in __do_global_ctors_aux () at
/home/fsirl/cvsx/gccm/libstdc++-v3/libsupc++/vec.cc:56
#8 0xff89e68 in _init () at /usr/include/stdlib.h:269
#9 0x300106ac in _start () from /lib/ld.so.1
(gdb)
This happens on both glibc-2.1.3 and glibc-2.2. Does anyone have an idea
what might have gone wrong here?
BTW, shouldn't c++filt now default to the V3 mangling style too?
Franz.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 13:54 Richard Kenner
@ 2000-11-20 14:59 ` Mark Mitchell
0 siblings, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-20 14:59 UTC (permalink / raw)
To: kenner; +Cc: gcc
>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:
Richard> One would hope they'd have the same policy: a released
Richard> version of a tool can only depend on a released version
Richard> of GCC.
Again, I don't think we're talking about a situation like that -- but
I agree with your suggested policy.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
[not found] ` <00112021562300.00259@hallo>
@ 2000-11-20 14:58 ` Mark Mitchell
2000-11-21 14:14 ` Geoff Keating
0 siblings, 1 reply; 37+ messages in thread
From: Mark Mitchell @ 2000-11-20 14:58 UTC (permalink / raw)
To: hartmut.schirmer; +Cc: gcc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
>>>>> "Hartmut" == Hartmut Schirmer <hartmut.schirmer@arcormail.de> writes:
Hartmut> On Mon, 20 Nov 2000, Mark Mitchell wrote:
>> The attitude at the time the release criteria were put together
>> was that you could always use GCC 2.95 if you wanted an ABI
>> compatible with GCC 2.95. :-)
Hartmut> But we´re waiting for gcc 2.95.3 for more than a year now
Hartmut> :((
There aren't currently any plans for such a release, but the Steering
Committe is debating such a release even as we speak.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
@ 2000-11-20 13:54 Richard Kenner
2000-11-20 14:59 ` Mark Mitchell
0 siblings, 1 reply; 37+ messages in thread
From: Richard Kenner @ 2000-11-20 13:54 UTC (permalink / raw)
To: mark; +Cc: gcc
We're talking about other tools that depend on GCC.
One would hope they'd have the same policy: a released version of a
tool can only depend on a released version of GCC.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 8:49 Richard Kenner
@ 2000-11-20 11:11 ` Mark Mitchell
0 siblings, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-20 11:11 UTC (permalink / raw)
To: kenner; +Cc: gcc
>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:
Richard> It used to be the case that the policy of the GCC project
Richard> was not to depend on any tool that has not yet been
Richard> released. Has that changed?
Not to my knowledge -- but I don't think we're not talking about that.
We're talking about other tools that depend on GCC.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
@ 2000-11-20 8:49 Richard Kenner
2000-11-20 11:11 ` Mark Mitchell
0 siblings, 1 reply; 37+ messages in thread
From: Richard Kenner @ 2000-11-20 8:49 UTC (permalink / raw)
To: mark; +Cc: gcc
In at least a narrow interpretation, we're not talking about that.
The GCC code will be tested, stable, etc. The issue is whether or not
all the supporting tools will have caught up.
It used to be the case that the policy of the GCC project was not
to depend on any tool that has not yet been released. Has that changed?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 3:32 ` Marc Espie
2000-11-20 5:53 ` Joseph S. Myers
@ 2000-11-20 8:34 ` Mark Mitchell
1 sibling, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-20 8:34 UTC (permalink / raw)
To: espie; +Cc: gcc
>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:
Marc> Well, some other people take a more conservative approach
Marc> and don't want to unleash DEVELOPMENT code on the general
Marc> public.
In at least a narrow interpretation, we're not talking about that.
The GCC code will be tested, stable, etc. The issue is whether or not
all the supporting tools will have caught up.
I hope they will have, and as GCC people, we should encourage those
people to catch up. But, everyone has their own priorities, and
exactly what the GDB folks (for example) are up to is not something
the GCC SC really knows about.
This is a weakness is the free software development model: there isn't
a global, centralizing authority to make everything happen in a
coordinated way. Companies (Red Hat, SuSE, etc.) have sprung up to
provide that value add. And that lack of central authority is also
the strength of the free software model.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 3:32 ` Marc Espie
@ 2000-11-20 5:53 ` Joseph S. Myers
2000-11-20 8:34 ` Mark Mitchell
1 sibling, 0 replies; 37+ messages in thread
From: Joseph S. Myers @ 2000-11-20 5:53 UTC (permalink / raw)
To: Marc Espie; +Cc: mark, gcc
On Mon, 20 Nov 2000, Marc Espie wrote:
> (for instance, have
> a look at gcc's info documentation. It's incomplete. Why ? because people want
> to write code, not documentation).
I have proposed in
<URL: http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00381.html > that
documentation be a mandatory part of patches for which it is applicable.
Hopefully this proposal is being considered.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 0:55 ` Mark Mitchell
@ 2000-11-20 3:32 ` Marc Espie
2000-11-20 5:53 ` Joseph S. Myers
2000-11-20 8:34 ` Mark Mitchell
[not found] ` <00112021562300.00259@hallo>
1 sibling, 2 replies; 37+ messages in thread
From: Marc Espie @ 2000-11-20 3:32 UTC (permalink / raw)
To: mark; +Cc: gcc
In article < 20001120005458Q.mitchell@codesourcery.com > you write:
>Nowadays, what tends to happen for GNU/Linux users is that somebody
>(Debian, Red Hat, etc) puts together a nice package with everyting in
>it. I wouldn't expect GCC 3.0 to appear in those distributions until
>other tools are in place. You're correct that users that aren't
>getting their GNU diet spoon-fed to them (:-)) may have to download
>development versions of some supporting tools. If we wait until all
>those tools are ready, though, we'll likely be waiting a long time...
Well, some other people take a more conservative approach and don't want
to unleash DEVELOPMENT code on the general public. I still think it is
completely, utterly WRONG to release development code in a so-called `stable'
release. If anything, it gives the impression that free software is put
together hastily, and does work slightly better than windows, but with lots
of bugs.
How about trying to entice the OTHER projects that are maintained by the FSF
to keep track and get a somewhat DECENT release schedule ?
I could even put forward a majorly NEW concept: how about having RELEASE DATES
for RELATED gnu projects ? Namely, you've got what we would call a
toolchain (binutils, gcc, gdb...). How about releasing a STABLE version
every year (say, 1st of january) ? and ensuring that the current year versions
work together ?
The one thing I do agree is that this is NOT FUN STUFF AT ALL.
Well, ethically, `free software' is not always fun. Having a heck of a good
time hacking also means a few hours should be sunk into the not funny parts.
Like documenting, or offering a wee little bit of support for stable versions.
In my opinion, the reason it does not quite work now is that most people just
work on the stuff that's fun for them. There are a few contributors who DO
deal with the `unnice' parts of it... (Invariably, they are also the guys who
don't really have the time for that) not enough though (for instance, have
a look at gcc's info documentation. It's incomplete. Why ? because people want
to write code, not documentation).
If you are a gcc contributor, ask yourself that question: what have you done
for gcc last year ? Was it all a fun hobby, or did you also help with other
chores ? If not, WHY NOT ???
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 17:10 ` Geoff Keating
2000-11-19 17:24 ` Christopher Faylor
2000-11-19 17:56 ` Mark Mitchell
@ 2000-11-20 2:54 ` Franz Sirl
2000-11-21 6:38 ` Franz Sirl
2 siblings, 1 reply; 37+ messages in thread
From: Franz Sirl @ 2000-11-20 2:54 UTC (permalink / raw)
To: Geoff Keating; +Cc: Mark Mitchell, gcc
At 02:10 20.11.00, Geoff Keating wrote:
>Mark Mitchell <mark@codesourcery.com> writes:
>
> > I plan on doing a `cvs remove' on the V2 sources, and removing the
> > configury bits for V2 at the end of next week as things seem to be
> > settling OK with V3. (There are still some AIX issues with V3, but
> > they seem to be well on the path to resolution.)
> >
> > If you have objections to this plan (i.e., you need the V2 sources to
> > continue your work), you should:
> >
> > - Try hard to get V3 working on your platform.
> >
> > - Complain to me. Explain why you can't switch to V3, and what
> > you need in order to make that happen.
> >
> > We can keep V2 in the tree for a bit longer, if we need to, but you'll
> > have to come up with a good reason... :-)
>
>The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with
>V3; I
>don't believe anyone, certainly not at Red Hat, will be able to fix
>this until next month; we don't have time.
Well, not only the embedded stuff is non-functional, powerpc-linux-gnu is
unusable with libstdc++-v3 too (see my posted testsuite results). I
couldn't do too much debugging yet, but it seems most (if not all) of the
testcases crash during constructor handling in glibc's malloc/free code.
Franz.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 1:07 ` Mark Mitchell
@ 2000-11-20 2:11 ` Geoff Keating
0 siblings, 0 replies; 37+ messages in thread
From: Geoff Keating @ 2000-11-20 2:11 UTC (permalink / raw)
To: mark; +Cc: gcc
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Mon, 20 Nov 2000 01:07:11 -0800
> Geoff --
>
> Where do I but the site.exp you sent? In place of the
>
> DEJAGNU=/home/s1/cygnus/dejagnu/site.exp
>
> file?
Yes.
You only have to do this if you want to do testing and might forget to
enter --target_board:
make check RUNTESTFLAGS=--target_board=powerpc-sim
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 22:12 ` Geoff Keating
2000-11-19 22:33 ` Mark Mitchell
@ 2000-11-20 1:07 ` Mark Mitchell
2000-11-20 2:11 ` Geoff Keating
2000-11-21 10:56 ` Mark Mitchell
2 siblings, 1 reply; 37+ messages in thread
From: Mark Mitchell @ 2000-11-20 1:07 UTC (permalink / raw)
To: geoffk, geoffk; +Cc: gcc
Geoff --
Where do I but the site.exp you sent? In place of the
DEJAGNU=/home/s1/cygnus/dejagnu/site.exp
file?
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-20 0:41 ` Andrew Cagney
@ 2000-11-20 0:55 ` Mark Mitchell
2000-11-20 3:32 ` Marc Espie
[not found] ` <00112021562300.00259@hallo>
0 siblings, 2 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-20 0:55 UTC (permalink / raw)
To: ac131313; +Cc: gcc
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Mark Mitchell wrote:
>> I plan on doing a `cvs remove' on the V2 sources, and removing
>> the configury bits for V2 at the end of next week as things
>> seem to be settling OK with V3. (There are still some AIX
>> issues with V3, but they seem to be well on the path to
>> resolution.)
>>
>> If you have objections to this plan (i.e., you need the V2
>> sources to continue your work), you should:
>>
>> - Try hard to get V3 working on your platform.
>>
>> - Complain to me. Explain why you can't switch to V3, and what
>> you need in order to make that happen.
Andrew> Do you really want to do this?
Andrew> Wouldn't it be better to take a more staggered approach?
Andrew> First release a GCC with both v2 and v3 ABI support and
Andrew> then release a successor that only contains v3 support.
We could do that. The SC decided a while back *not* to do that, but
it/we could change its/our collective mind.
The issue is that the new ABI implies the use of V3; V2 does not work
with the new ABI. We want to stop breaking the C++ ABI; that's one
major impetus for GCC 3.0. If we provide both ABIs, we're encouraging
people to use the old ABI, which is not quite the same as what was in
GCC 2.95.x, but is also not what we want to use going forward.
The attitude at the time the release criteria were put together was
that you could always use GCC 2.95 if you wanted an ABI compatible
with GCC 2.95. :-) In other words, there was a conscious decision not
to support the old ABI in GCC 3.0, with the hope of never again
chaging the C++ ABI.
Andrew> I expect many people to try to use GCC with pre installed
Andrew> tools (GDB comes to mind). Requiring people to upgrade to
Andrew> some not-yet-even-developed version of random tools is
Andrew> going to raise a few eyebrows.
Nowadays, what tends to happen for GNU/Linux users is that somebody
(Debian, Red Hat, etc) puts together a nice package with everyting in
it. I wouldn't expect GCC 3.0 to appear in those distributions until
other tools are in place. You're correct that users that aren't
getting their GNU diet spoon-fed to them (:-)) may have to download
development versions of some supporting tools. If we wait until all
those tools are ready, though, we'll likely be waiting a long time...
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 13:03 ` Mark Mitchell
2000-11-19 17:10 ` Geoff Keating
@ 2000-11-20 0:41 ` Andrew Cagney
2000-11-20 0:55 ` Mark Mitchell
1 sibling, 1 reply; 37+ messages in thread
From: Andrew Cagney @ 2000-11-20 0:41 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
Mark Mitchell wrote:
>
> I plan on doing a `cvs remove' on the V2 sources, and removing the
> configury bits for V2 at the end of next week as things seem to be
> settling OK with V3. (There are still some AIX issues with V3, but
> they seem to be well on the path to resolution.)
>
> If you have objections to this plan (i.e., you need the V2 sources to
> continue your work), you should:
>
> - Try hard to get V3 working on your platform.
>
> - Complain to me. Explain why you can't switch to V3, and what
> you need in order to make that happen.
Do you really want to do this?
Wouldn't it be better to take a more staggered approach? First release
a GCC with both v2 and v3 ABI support and then release a successor that
only contains v3 support.
I expect many people to try to use GCC with pre installed tools (GDB
comes to mind). Requiring people to upgrade to some
not-yet-even-developed version of random tools is going to raise a few
eyebrows.
(perhaps I'm misunderstanding the significance of the change)
enjoy,
Andrew
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 22:12 ` Geoff Keating
@ 2000-11-19 22:33 ` Mark Mitchell
2000-11-20 1:07 ` Mark Mitchell
2000-11-21 10:56 ` Mark Mitchell
2 siblings, 0 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-19 22:33 UTC (permalink / raw)
To: geoffk, geoffk; +Cc: gcc
Youch!
OK, I'll try that script soon.
Tomorrow is my wife's birthday, so not until Tuesday at the soonest...
Thanks!
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 21:52 ` Mark Mitchell
@ 2000-11-19 22:12 ` Geoff Keating
2000-11-19 22:33 ` Mark Mitchell
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Geoff Keating @ 2000-11-19 22:12 UTC (permalink / raw)
To: mark; +Cc: gcc
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sun, 19 Nov 2000 21:51:57 -0800
> Or, alternatively, a way to build a cross-compiler plus simulator so
> that I can test a newlib configuration on my PC?
Sure.
I have a script for this, which the automated tester uses. Just
change TOPDIR to somewhere on your machine.
[The complexity of this script is why people keep agitating
for a combined tree.]
--
- Geoffrey Keating <geoffk@geoffk.org>
===File ~/buildobjs.sh======================================
#!/usr/unsupported/bin/bash
set -x
TARGET=powerpc-eabisim
CVSROOT_BIN=':pserver:anoncvs@anoncvs.cygnus.com:/cvs/src'
CVSROOT_GCC=':pserver:anoncvs@anoncvs.cygnus.com:/cvs/gcc'
TOPDIR=/sloth/delay/tbox
CVS_DIR=$TOPDIR/cvs-objs
SRC_XC=$CVS_DIR/gcc
SRC_BIN=$CVS_DIR/binutils
SRC_DIR=$TOPDIR/src-objs
INSTALL_DIR=$TOPDIR/objs
OBJ_DIR=$TOPDIR/build-objs
SCRIPT_DIR=$HOME/tbox
rm -rf $OBJ_DIR $INSTALL_DIR $SRC_DIR
mkdir $OBJ_DIR $INSTALL_DIR $SRC_DIR || exit 1
mkdir $OBJ_DIR/src $OBJ_DIR/test || exit 1
mkdir -p $SRC_XC $SRC_BIN || exit 1
PATH=/bin:/usr/bin
PATH=$INSTALL_DIR/bin:$TOPDIR/boot/bin:$PATH
export PATH
cd $SRC_XC || exit 1
cvs -Q -d $CVSROOT_GCC co egcs-full || exit 1
cd $SRC_BIN || exit 1
cvs -Q -d $CVSROOT_BIN co binutils gdb newlib dejagnu || exit 1
# the order here is important, the GCC files are the master copy.
cd $SRC_BIN/src || exit 1
find . -print | cpio -pdlm $SRC_DIR || exit 1
cd $SRC_XC/egcs || exit 1
find . -print | cpio -pdlmu $SRC_DIR || exit 1
cd $SRC_DIR || exit 1
[ -x contrib/gcc_update ] && contrib/gcc_update --touch > /dev/null
cd $OBJ_DIR/src || exit 1
$SRC_DIR/configure --prefix=$INSTALL_DIR --target=$TARGET || exit 1
make all || exit 1
make install || exit 1
DEJAGNU=/home/s1/cygnus/dejagnu/site.exp
export DEJAGNU
cd $OBJ_DIR/test || exit 1
$SRC_XC/egcs/configure --target=$TARGET \
--prefix=$INSTALL_DIR --enable-checking=misc,gc,tree || exit 1
make || exit 1
make -k check-gcc check-target-libio check-target-libstdc++
exit 0
============================================================
===File ~/lib/site.exp======================================
# Needed for isnative.
load_lib "framework.exp"
# Make sure we look in the right place for the board description files.
if ![info exists boards_dir] {
set boards_dir {}
}
lappend boards_dir "/home/geoffk/lib/dejagnu"
#
# If we're testing GCC, G++ or GDB, then we want to run on all the
# available targets. Otherwise, just test the first one.
#
if ![info exists tool] {
set run_multiple_targets 0;
} elseif { $tool == "g++" || $tool == "gcc" || $tool == "gdb" || $tool == "libg++" || $tool == "libstdc++" || $tool == "libio" || $tool == "binutils" } {
set run_multiple_targets 1;
} else {
set run_multiple_targets 0;
}
verbose "Global Config File: target_triplet is $target_triplet" 2
global target_list
case "$target_triplet" in {
{ "native" } { set target_list "unix" }
{ "powerpc-*-eabi" } { set target_list { powerpc-sim } }
{ "powerpc-*-eabisim" } { set target_list { powerpc-sim } }
}
#
# If the tool under test won't really benefit from running on multiple
# targets, then don't do so.
#
if { ! $run_multiple_targets } {
set target_list [list [lindex $target_list 0]];
}
============================================================
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 20:24 ` Geoff Keating
@ 2000-11-19 21:52 ` Mark Mitchell
2000-11-19 22:12 ` Geoff Keating
0 siblings, 1 reply; 37+ messages in thread
From: Mark Mitchell @ 2000-11-19 21:52 UTC (permalink / raw)
To: geoffk, geoffk; +Cc: gcc
>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:
>> Put simply, I don't think that is an issue for the FSF
>> release. None of these platforms are on primary release
>> criteria list.
Geoff> I didn't understand this part, and so I couldn't understand
Geoff> much of the rest of your mail either.
Sorry. I was referencing the list of platforms that the SC has
decided are primary targets for GCC 3.0; none of those targets are
embedded systems.
Geoff> What does the release or the release criteria have to do
Geoff> with it? I was objecting to the deletion of libstdc++-v2
Geoff> from the development tree, on the grounds that this would
Geoff> make it harder to do development. I would have no
Geoff> objection to its deletion from the release branch, if it's
Geoff> doing the right thing, go ahead.
The problem is that these things aren't entirely orthogonal. The ABI,
the library version, and the performance of the compiler are all
intertwined. It's not just the question of dragging the sources
around; it's more complex than that.
There's also the issue that port maintainers need to invest the effort
to switch to V3 because that's what we're going to support going
forward. I'd really like to get a handle on whether that porting
effort is truly difficult or not. (It wasn't difficult on the
platforms I worked on, but, on the other hand, it has been pointed out
that those were both SVR4-ish platforms.)
Geoff> The counter-example here is i960; there are no non-embedded
Geoff> alternatives (the choices are -coff, -elf, and -vxworks),
Geoff> and it does have C++ support.
OK. But I still don't really understand the scenario you're talking
about. It seems to me there are a few cases:
- Change to the i960 back-end in your tree. You can test in your
tree, and you can test C/Fortran/ObjC in the public tree. By
hypothesis, the public tree doesn't have i960 C++ support any
more, since the scenario we're talking about is one where we
don't have V2 in the public tree, and V3 doesn't work on the
i960. So, nobody can complain about your change breaking
i960 C++.
- Change to the C++ front-end in your tree. Likely this change
is not i960-specific. You can test with another chip. If it
*is* i960 specific, then you're in the same boat as above:
there's no i960 C++ support anyhow.
So, I'm afraid I still don't understand the testing argument.
Is there anyone out there who is willing to try a newlib port of V3?
Is it possible to build newlib on an i686-pc-linux-gnu box, using it
natively, instead of glibc? If so, would you tell me how to do this?
Or, alternatively, a way to build a cross-compiler plus simulator so
that I can test a newlib configuration on my PC?
If you will tell me how to build all the pieces, I will try to figure
out how to make V3 work in that environment. If I were to make that
work, would that reduce your objection to removing the V2 sources?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 17:56 ` Mark Mitchell
@ 2000-11-19 20:24 ` Geoff Keating
2000-11-19 21:52 ` Mark Mitchell
0 siblings, 1 reply; 37+ messages in thread
From: Geoff Keating @ 2000-11-19 20:24 UTC (permalink / raw)
To: mark; +Cc: gcc
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sun, 19 Nov 2000 17:56:08 -0800
> >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> 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.
I didn't understand this part, and so I couldn't understand much of
the rest of your mail either.
What does the release or the release criteria have to do with it? I
was objecting to the deletion of libstdc++-v2 from the development
tree, on the grounds that this would make it harder to do development.
I would have no objection to its deletion from the release branch, if
it's not needed for the release.
I don't really care. I just wanted to try to avoid a possibly
annoying mistake. If you really think you're doing the right thing,
go ahead.
> 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.
The counter-example here is i960; there are no non-embedded
alternatives (the choices are -coff, -elf, and -vxworks), and it does
have C++ support.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 17:10 ` Geoff Keating
2000-11-19 17:24 ` Christopher Faylor
@ 2000-11-19 17:56 ` Mark Mitchell
2000-11-19 20:24 ` Geoff Keating
2000-11-20 2:54 ` Franz Sirl
2 siblings, 1 reply; 37+ messages in thread
From: Mark Mitchell @ 2000-11-19 17:56 UTC (permalink / raw)
To: geoffk; +Cc: gcc
>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> 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
Geoff> customers.
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
for everything.
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
harder?
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 mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: Removal of V2 code
@ 2000-11-19 17:40 Billinghurst, David (CRTS)
0 siblings, 0 replies; 37+ messages in thread
From: Billinghurst, David (CRTS) @ 2000-11-19 17:40 UTC (permalink / raw)
To: 'Christopher Faylor', Geoff Keating; +Cc: Mark Mitchell, gcc
I can't get cygwin to bootstrap, and haven't since early september. Given
this, it is difficult to confirm that the change to V3 works
> -----Original Message-----
> From: Christopher Faylor [SMTP:cgf@redhat.com]
> Sent: Monday, 20 November 2000 12:24
> To: Geoff Keating
> Cc: Mark Mitchell; gcc@gcc.gnu.org
> Subject: Re: Removal of V2 code
>
> On Sun, Nov 19, 2000 at 05:10:33PM -0800, Geoff Keating wrote:
> >Mark Mitchell <mark@codesourcery.com> writes:
> >> I plan on doing a `cvs remove' on the V2 sources, and removing the
> >> configury bits for V2 at the end of next week as things seem to be
> >> settling OK with V3. (There are still some AIX issues with V3, but
> >> they seem to be well on the path to resolution.)
> >>
> >> If you have objections to this plan (i.e., you need the V2 sources to
> >> continue your work), you should:
> >>
> >> - Try hard to get V3 working on your platform.
> >>
> >> - Complain to me. Explain why you can't switch to V3, and what
> >> you need in order to make that happen.
> >>
> >> We can keep V2 in the tree for a bit longer, if we need to, but you'll
> >> have to come up with a good reason... :-)
> >
> >The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with
> V3; I
> >don't believe anyone, certainly not at Red Hat, will be able to fix
> >this until next month; we don't have time.
> >
> >I don't know what the vxworks status is, but I'd bet it doesn't work
> either.
> >
> >I don't know what the Cygwin status is. It may work.
>
> Cygwin should be ok.
>
> cgf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 17:10 ` Geoff Keating
@ 2000-11-19 17:24 ` Christopher Faylor
2000-11-19 17:56 ` Mark Mitchell
2000-11-20 2:54 ` Franz Sirl
2 siblings, 0 replies; 37+ messages in thread
From: Christopher Faylor @ 2000-11-19 17:24 UTC (permalink / raw)
To: Geoff Keating; +Cc: Mark Mitchell, gcc
On Sun, Nov 19, 2000 at 05:10:33PM -0800, Geoff Keating wrote:
>Mark Mitchell <mark@codesourcery.com> writes:
>> I plan on doing a `cvs remove' on the V2 sources, and removing the
>> configury bits for V2 at the end of next week as things seem to be
>> settling OK with V3. (There are still some AIX issues with V3, but
>> they seem to be well on the path to resolution.)
>>
>> If you have objections to this plan (i.e., you need the V2 sources to
>> continue your work), you should:
>>
>> - Try hard to get V3 working on your platform.
>>
>> - Complain to me. Explain why you can't switch to V3, and what
>> you need in order to make that happen.
>>
>> We can keep V2 in the tree for a bit longer, if we need to, but you'll
>> have to come up with a good reason... :-)
>
>The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with V3; I
>don't believe anyone, certainly not at Red Hat, will be able to fix
>this until next month; we don't have time.
>
>I don't know what the vxworks status is, but I'd bet it doesn't work either.
>
>I don't know what the Cygwin status is. It may work.
Cygwin should be ok.
cgf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Removal of V2 code
2000-11-19 13:03 ` Mark Mitchell
@ 2000-11-19 17:10 ` Geoff Keating
2000-11-19 17:24 ` Christopher Faylor
` (2 more replies)
2000-11-20 0:41 ` Andrew Cagney
1 sibling, 3 replies; 37+ messages in thread
From: Geoff Keating @ 2000-11-19 17:10 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
Mark Mitchell <mark@codesourcery.com> writes:
> I plan on doing a `cvs remove' on the V2 sources, and removing the
> configury bits for V2 at the end of next week as things seem to be
> settling OK with V3. (There are still some AIX issues with V3, but
> they seem to be well on the path to resolution.)
>
> If you have objections to this plan (i.e., you need the V2 sources to
> continue your work), you should:
>
> - Try hard to get V3 working on your platform.
>
> - Complain to me. Explain why you can't switch to V3, and what
> you need in order to make that happen.
>
> We can keep V2 in the tree for a bit longer, if we need to, but you'll
> have to come up with a good reason... :-)
The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with V3; I
don't believe anyone, certainly not at Red Hat, will be able to fix
this until next month; we don't have time.
I don't know what the vxworks status is, but I'd bet it doesn't work either.
I don't know what the Cygwin status is. It may work.
Do HPUX, IRIX, BeOS work?
Does SunOS (not Solaris) work? I think we still have SunOS customers.
At Red Hat we have not switched over to V3, primarily for this reason.
Such a change will make it difficult for us to merge patches back into
the FSF sources, because we would not be able to test them. We would
end up committing patches saying "have tested with C++ only on our
internal sources, due to no libstdc++ support in the public tree".
Already you can see this effect; you will notice that the automated
tester is no longer testing C++ because the platform it tests with
is not supported by libstdc++-v3.
I believe this schedule is far too quick. We have only had
libstdc++-v3 as the default for a few weeks, there are
known problems, these problems will take some time to fix.
I would wait 6 months and ask again.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Removal of V2 code
@ 2000-11-19 13:03 ` Mark Mitchell
2000-11-19 17:10 ` Geoff Keating
2000-11-20 0:41 ` Andrew Cagney
0 siblings, 2 replies; 37+ messages in thread
From: Mark Mitchell @ 2000-11-19 13:03 UTC (permalink / raw)
To: gcc
I plan on doing a `cvs remove' on the V2 sources, and removing the
configury bits for V2 at the end of next week as things seem to be
settling OK with V3. (There are still some AIX issues with V3, but
they seem to be well on the path to resolution.)
If you have objections to this plan (i.e., you need the V2 sources to
continue your work), you should:
- Try hard to get V3 working on your platform.
- Complain to me. Explain why you can't switch to V3, and what
you need in order to make that happen.
We can keep V2 in the tree for a bit longer, if we need to, but you'll
have to come up with a good reason... :-)
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2000-11-21 21:41 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-20 8:55 Removal of V2 code Kaveh R. Ghazi
2000-11-20 9:46 ` sun/os as release candidate was: " Robert Lipe
2000-11-20 17:59 ` Gerald Pfeifer
2000-11-20 9:47 ` law
-- strict thread matches above, loose matches on Subject: below --
2000-11-20 13:54 Richard Kenner
2000-11-20 14:59 ` Mark Mitchell
2000-11-20 8:49 Richard Kenner
2000-11-20 11:11 ` Mark Mitchell
2000-11-19 17:40 Billinghurst, David (CRTS)
[not found] <Mark>
[not found] ` <Mitchell's>
[not found] ` <message>
[not found] ` <of>
[not found] ` <"Sun,>
[not found] ` <19>
[not found] ` <Nov>
[not found] ` <2000>
[not found] ` <13:03:48>
[not found] ` <-0800>
2000-11-19 13:03 ` Mark Mitchell
2000-11-19 17:10 ` Geoff Keating
2000-11-19 17:24 ` Christopher Faylor
2000-11-19 17:56 ` Mark Mitchell
2000-11-19 20:24 ` Geoff Keating
2000-11-19 21:52 ` Mark Mitchell
2000-11-19 22:12 ` Geoff Keating
2000-11-19 22:33 ` Mark Mitchell
2000-11-20 1:07 ` Mark Mitchell
2000-11-20 2:11 ` Geoff Keating
2000-11-21 10:56 ` Mark Mitchell
2000-11-21 12:20 ` Benjamin Kosnik
2000-11-21 12:45 ` Mark Mitchell
2000-11-21 12:37 ` Geoff Keating
2000-11-21 12:47 ` Mark Mitchell
2000-11-20 2:54 ` Franz Sirl
2000-11-21 6:38 ` Franz Sirl
2000-11-21 7:26 ` Daniel Berlin
2000-11-20 0:41 ` Andrew Cagney
2000-11-20 0:55 ` Mark Mitchell
2000-11-20 3:32 ` Marc Espie
2000-11-20 5:53 ` Joseph S. Myers
2000-11-20 8:34 ` Mark Mitchell
[not found] ` <00112021562300.00259@hallo>
2000-11-20 14:58 ` Mark Mitchell
2000-11-21 14:14 ` Geoff Keating
2000-11-21 15:06 ` Mark Mitchell
2000-11-21 16:08 ` Tom Tromey
2000-11-21 21:41 ` Mark Mitchell
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).