Discussion:
Obsolete configurations, round 3
Zack Weinberg
2002-04-16 17:04:45 UTC
Permalink
Here is my current list of targets to deprecate.

a29k-*-*
arm-*-riscix*
c*-convex-*
elxsi-*-*
i?86-*-aix*
i?86-*-bsd*
i?86-*-chorusos*
i?86-*-dgux*
i?86-*-freebsd1.*
i?86-*-isc*
i?86-*-linux*oldld*
i?86-*-osf1*
i?86-*-osfrose*
i?86-*-rtemscoff*
i?86-*-sunos*
i?86-go32-rtems*
i?86-next-*
i?86-sequent-bsd*
i?86-sequent-ptx[12]*
i?86-sequent-sysv3*
m68[k0]*-*-lynxos*
m68[k0]*-*-rtemscoff*
m68[k0]*-*-sysv3*
m68[k0]*-altos-*
m68[k0]*-apollo-*
m68[k0]*-apple-*
m68[k0]*-bull-*
m68[k0]*-convergent-*
m68[k0]*-isi-*
m68[k0]*-next-*
m68[k0]*-sony-*
ns32k-encore-*
ns32k-merlin-*
ns32k-pc532-*
ns32k-sequent-*
ns32k-tek6[12]00-*
sparc-*-rtemsaout*

Speak up if you want one of these kept.

For further suggestions, I would like to look mostly at entire machine
architectures that could be dropped. Possible candidates for this are

1750a currently doesn't build on mainline due to
lack of support for idiosyncratic floating
point format
clipper intergraph's still around, but no port
activity since 2.95
d30v rumor has it this never taped out
i370 superseded by s390?
i860 dead since early 90s, IIRC
m88k same situation as ns32k - some netbsd/openbsd
port activity, all commercial support abandoned
pj abandoned by sun?
romp eol-ed in 1992 or so
we32k western electric went out of business

zw
Richard Kenner
2002-04-16 17:06:03 UTC
Permalink
a29k-*-*

I can't make a very strong argument for keeping this, but a weak one is
that it's a good example of a nearly "pure" RISC port.
Lars Brinkhoff
2002-04-16 17:15:23 UTC
Permalink
Zack Weinberg <***@codesourcery.com> writes:
> I would like to look mostly at entire machine architectures that
> could be dropped [from GCC]. Possible candidates for this are:
> ...
> romp eol-ed in 1992 or so

http://www.openbsd.org/romp.html
says that a port is being organized, but it seems that was written in
1998, and the mailing list archive doesn't show much recent activity.

--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Zack Weinberg
2002-04-16 18:24:54 UTC
Permalink
On Tue, Apr 16, 2002 at 07:15:23PM +0200, Lars Brinkhoff wrote:
> Zack Weinberg <***@codesourcery.com> writes:
> > I would like to look mostly at entire machine architectures that
> > could be dropped [from GCC]. Possible candidates for this are:
> > ...
> > romp eol-ed in 1992 or so
>
> http://www.openbsd.org/romp.html
> says that a port is being organized, but it seems that was written in
> 1998, and the mailing list archive doesn't show much recent activity.

I know; I used to have one of those and follow the mailing list. It
never got off the ground, as far as I could tell. If someone wants to
speak up for that port, fine; otherwise, I don't see any value in
keeping it around.

zw
Jim Mercer
2002-04-16 19:05:35 UTC
Permalink
On Tue, Apr 16, 2002 at 11:24:54AM -0700, Zack Weinberg wrote:
> On Tue, Apr 16, 2002 at 07:15:23PM +0200, Lars Brinkhoff wrote:
> > Zack Weinberg <***@codesourcery.com> writes:
> > > I would like to look mostly at entire machine architectures that
> > > could be dropped [from GCC]. Possible candidates for this are:
> > > ...
> > > romp eol-ed in 1992 or so
> >
> > http://www.openbsd.org/romp.html
> > says that a port is being organized, but it seems that was written in
> > 1998, and the mailing list archive doesn't show much recent activity.
>
> I know; I used to have one of those and follow the mailing list. It
> never got off the ground, as far as I could tell. If someone wants to
> speak up for that port, fine; otherwise, I don't see any value in
> keeping it around.

but, but, but!

what am i to do with my collection of RT/romp gear if there is no compiler
for it?

8^)

thus far i don't see anyone making any noise.
(although i'm in no way authorative for the ROMP community)

--
[ Jim Mercer ***@reptiles.org +1 416 410-5633 ]
[ I want to live forever, or die trying. ]
j***@dsb.tudelft.nl
2002-04-16 20:09:52 UTC
Permalink
On Tue, Apr 16, 2002 at 03:05:35PM -0400, Jim Mercer wrote:
> On Tue, Apr 16, 2002 at 11:24:54AM -0700, Zack Weinberg wrote:
> > On Tue, Apr 16, 2002 at 07:15:23PM +0200, Lars Brinkhoff wrote:
> > > Zack Weinberg <***@codesourcery.com> writes:
> > > > I would like to look mostly at entire machine architectures that
> > > > could be dropped [from GCC]. Possible candidates for this are:

What's the deal with dropping ports from gcc, btw?

> > > > ...
> > > > romp eol-ed in 1992 or so
> > >
> > > http://www.openbsd.org/romp.html
> > > says that a port is being organized, but it seems that was written in
> > > 1998, and the mailing list archive doesn't show much recent activity.
> >
> > I know; I used to have one of those and follow the mailing list. It
> > never got off the ground, as far as I could tell. If someone wants to
> > speak up for that port, fine; otherwise, I don't see any value in
> > keeping it around.

The OpenBSD/romp port never saw light, AFAICT, but there is/was some
4.4BSD work going on.

> but, but, but!
>
> what am i to do with my collection of RT/romp gear if there is no compiler
> for it?

Even tho I don't own a romp anymore, I can think of a few reasons to
keep a compiler for it. One is, ofcourse, historical interrest: It
is AFAIK the first risc to run un*x.

> thus far i don't see anyone making any noise.

'ey, if there's one message in a week people start to wonder how
busy the list has become. I wouln't be surprised if you lot just
caused a few heart attacks. :-)

--
j p d (at) d s b (dot) t u d e l f t (dot) n l
Miod Vallat
2002-04-16 20:14:58 UTC
Permalink
> The OpenBSD/romp port never saw light, AFAICT, but there is/was some
> 4.4BSD work going on.

Actually, there is some OpenBSD/romp work slowly going on, but we have
better use for our spare time...

If romp support is dropped from gcc, I guess it would not be too hard to
put it back if OpenBSD/romp becomes a reality.

Miod
Zack Weinberg
2002-04-17 18:55:36 UTC
Permalink
On Tue, Apr 16, 2002 at 10:09:52PM +0200, ***@dsb.tudelft.nl wrote:
>
> What's the deal with dropping ports from gcc, btw?

By dropping ports which no one cares about anymore, we reduce our
maintenance burden. Machine-independent changes don't have to worry
about the quirks of obsolete hardware or operating systems.

> Even tho I don't own a romp anymore, I can think of a few reasons to
> keep a compiler for it. One is, ofcourse, historical interrest: It
> is AFAIK the first risc to run un*x.

I don't think that historical interest is sufficient reason to keep
code around, when it is unused and adds complexity to the compiler
merely by existing.

However, I said earlier that we were only going to drop ports with no
constituents at all in this round, so romp-*-openbsd stays. (Do you
have any objection to ditching romp-*-aos and romp-*-mach?)

zw
j***@dsb.tudelft.nl
2002-04-19 06:46:38 UTC
Permalink
On Wed, Apr 17, 2002 at 11:55:36AM -0700, Zack Weinberg wrote:
[snip]
>
> However, I said earlier that we were only going to drop ports with no
^^^^^^^^^^^^^^
But not on ***@openbsd.org, hence the question. :-)

> constituents at all in this round, so romp-*-openbsd stays. (Do you
> have any objection to ditching romp-*-aos and romp-*-mach?)

As I suspect romp-*-aos would also be used for 4.4BSD it might be
`handy' to have gcc for it. However, since it is rather old itself
(and you're not very fond of historical intrerest :-) maybe 4.4BSD
(and AOS) can make-do with an older gcc. I've never even seen
romp-*-mach, so I can't comment on that.

This is just me speaking. (But since I'm about the only one, it seems,
it almost feels like being a spokesperson.)

--
j p d (at) d s b (dot) t u d e l f t (dot) n l
Jason R Thorpe
2002-04-16 22:25:33 UTC
Permalink
On Tue, Apr 16, 2002 at 11:24:54AM -0700, Zack Weinberg wrote:

> I know; I used to have one of those and follow the mailing list. It
> never got off the ground, as far as I could tell. If someone wants to
> speak up for that port, fine; otherwise, I don't see any value in
> keeping it around.

..and, hey, there's always the Attic...

--
-- Jason R. Thorpe <***@wasabisystems.com>
Peter A. Castro
2002-04-22 00:46:08 UTC
Permalink
On 16 Apr 2002, Lars Brinkhoff wrote:

> Zack Weinberg <***@codesourcery.com> writes:
> > I would like to look mostly at entire machine architectures that
> > could be dropped [from GCC]. Possible candidates for this are:
> > ...
> > romp eol-ed in 1992 or so
>
> http://www.openbsd.org/romp.html
> says that a port is being organized, but it seems that was written in
> 1998, and the mailing list archive doesn't show much recent activity.

Please don't drop ROMP. I'm still working on updates to GCC for ROMP in
prep for some porting work I'm doing (yes, some of still use the really
old hardware).

--
Peter A. Castro <***@fruitbat.org> or <***@oracle.com>
"Cats are just autistic Dogs" -- Dr. Tony Attwood
Richard Henderson
2002-04-16 17:21:41 UTC
Permalink
On Tue, Apr 16, 2002 at 10:04:45AM -0700, Zack Weinberg wrote:
> i370 superseded by s390?

s390 currently only works on linux, so i370 would still
be used for mvs. It'd be nice to fold whatever OS bits
into the new backend, but I certainly don't want to do
the work.

> pj abandoned by sun?

No, Sun had nothing to do with this -- it is sac's handiwork.
Poke him and see if he wants to actively maintain the thing,
otherwise kill it.

More for the list:

alpha*-*-osf[123]*

I expect everyone to be running osf[45].


r~
Joel Sherrill
2002-04-16 17:39:41 UTC
Permalink
Richard Henderson wrote:
>
> On Tue, Apr 16, 2002 at 10:04:45AM -0700, Zack Weinberg wrote:
> > i370 superseded by s390?
>
> s390 currently only works on linux, so i370 would still
> be used for mvs. It'd be nice to fold whatever OS bits
> into the new backend, but I certainly don't want to do
> the work.
>
> > pj abandoned by sun?
>
> No, Sun had nothing to do with this -- it is sac's handiwork.
> Poke him and see if he wants to actively maintain the thing,
> otherwise kill it.
>
> More for the list:
>
> alpha*-*-osf[123]*
>
> I expect everyone to be running osf[45].

What about elxsi-*-* and ns32k*-*-*?

A quick search of ChangeLogs only shows "likewise" type changes
for the past few years.

"elsxi -gcc" doesn't have any real hits on google so I have to
wonder about it.

Is the ns32k still available?

> r~

--
Joel Sherrill, Ph.D. Director of Research & Development
***@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Zack Weinberg
2002-04-16 18:05:49 UTC
Permalink
On Tue, Apr 16, 2002 at 12:39:41PM -0500, Joel Sherrill wrote:
>
> What about elxsi-*-* and ns32k*-*-*?

elxsi's already on my list. ns32k appears to still have interested
users in the Net/OpenBSD community so we're keeping it. We are
dumping all the other ns32k targets though.

Hmm, m88k's in the same boat. These look dead:

m88k-dg-*
m88k-dolphin-*
m88k-tektronix-*
m88k-*-luna*
m88k-*-sysv3*
m88k-*-coff* (?)

these should probably be kept:

m88k-*-aout*
m88k-*-openbsd*
m88k-*-sysv4* (as a basis for ELF ports)

zw
Gerald Pfeifer
2002-04-17 13:43:01 UTC
Permalink
BTW, before actually removing some configurations we should send
something to gcc-announce and wait for input from there.

(IIRC that's what has been decided some time ago, even though I
don't remember details...)

Gerald
--
Gerald "Jerry" ***@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
Jason R Thorpe
2002-04-16 22:27:15 UTC
Permalink
On Tue, Apr 16, 2002 at 12:39:41PM -0500, Joel Sherrill wrote:

> Is the ns32k still available?

There is still an active NetBSD port to the ns32k.

--
-- Jason R. Thorpe <***@wasabisystems.com>
Marc Espie
2002-04-17 00:05:53 UTC
Permalink
In article <***@codesourcery.com> you write:
To keep:
> m88k-*-openbsd*

Yes please.

Even though I haven't had time to look at gcc 3.1
and merge our local changes, all the OpenBSD configurations
are still alive.

Some of the ports are not too used, like mips.
Romp is half a ghost but not quite, but mvme88k still runs.


These days, OpenBSD exists on:
m68k, sparc, sparc64, i386, powerpc, vax, alpha.

The m88k port and the mips port are mostly alive (they were
working at some time in the not so distant past, and some people
are playing with it). hppa is coming together (I think it's
past single-boot on quite a few makes).

Romp might be some time in the future, who knows ?
Zack Weinberg
2002-04-16 18:23:34 UTC
Permalink
On Tue, Apr 16, 2002 at 10:21:41AM -0700, Richard Henderson wrote:
> On Tue, Apr 16, 2002 at 10:04:45AM -0700, Zack Weinberg wrote:
> > i370 superseded by s390?
>
> s390 currently only works on linux, so i370 would still
> be used for mvs.

Right.

> > pj abandoned by sun?
>
> No, Sun had nothing to do with this -- it is sac's handiwork.

sac == Steve Chamberlain <***@transmeta.com> ?

> alpha*-*-osf[123]*

Added.

zw
David S. Miller
2002-04-16 18:17:20 UTC
Permalink
From: Zack Weinberg <***@codesourcery.com>
Date: Tue, 16 Apr 2002 11:23:34 -0700

On Tue, Apr 16, 2002 at 10:21:41AM -0700, Richard Henderson wrote:
> > pj abandoned by sun?
>
> No, Sun had nothing to do with this -- it is sac's handiwork.

sac == Steve Chamberlain <***@transmeta.com> ?

Yes.
David Edelsohn
2002-04-16 17:38:02 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> i370 superseded by s390?

Not superceded. s390 is the SVR4/ELF/GNU/Linux port. i370 is the
MVS aka OS/390 aka z/OS port. The two should be merged, but i370 cannot
be dropped until that port's functionality is subsumed by s390 port.

Zack> i860 dead since early 90s, IIRC

Isn't this still used in some embedded products?

Zack> romp eol-ed in 1992 or so

*sniffle*

David
Zack Weinberg
2002-04-16 18:25:16 UTC
Permalink
On Tue, Apr 16, 2002 at 01:38:02PM -0400, David Edelsohn wrote:
> >>>>> Zack Weinberg writes:
>
> Zack> i860 dead since early 90s, IIRC
>
> Isn't this still used in some embedded products?

I believe that's i960.

zw
Richard Henderson
2002-04-16 19:57:03 UTC
Permalink
On Tue, Apr 16, 2002 at 11:25:16AM -0700, Zack Weinberg wrote:
> I believe that's i960.

Yep. The i960 zombie still lurks in the telecom arena;
as far as I know the i860 has been staked.


r~
l***@redhat.com
2002-04-16 20:06:26 UTC
Permalink
In message <***@redhat.com>, Richard Henderson writes:
> On Tue, Apr 16, 2002 at 11:25:16AM -0700, Zack Weinberg wrote:
> > I believe that's i960.
>
> Yep. The i960 zombie still lurks in the telecom arena;
> as far as I know the i860 has been staked.
Yup. i960 isn't totally dead yet -- Red Hat still has customers who use them.

jeff
Jason R Thorpe
2002-04-16 22:29:28 UTC
Permalink
On Tue, Apr 16, 2002 at 01:38:02PM -0400, David Edelsohn wrote:

> Zack> i860 dead since early 90s, IIRC
>
> Isn't this still used in some embedded products?

Dunno about embedded systems, but the herds of Paragon users will sure be
upset if this goes :-)

--
-- Jason R. Thorpe <***@wasabisystems.com>
Richard Kenner
2002-04-16 20:14:44 UTC
Permalink
Even tho I don't own a romp anymore, I can think of a few reasons to
keep a compiler for it. One is, ofcourse, historical interrest: It
is AFAIK the first risc to run un*x.

It is also the port that drove the features that distinguished between
GCC 1 and GCC 2.
Eric Christopher
2002-04-17 03:32:42 UTC
Permalink
On Tue, 16 Apr 2002 10:04:45 -0700, Zack Weinberg wrote:

> Here is my current list of targets to deprecate.

And I'd like to add:

mips-sni-sysv4
mips-sgi-irix4loser
mips-sgi-irix4
mips-sgi-irix[3..]
mips-dec-osfrose
mips-dec-osf
mips-dec-bsd
mips-sony-bsd* | mips-sony-newsos*
mips-sony-sysv
mips-tandem-sysv4
mips-*-ultrix* | mips-dec-mach3
mips-*-riscos[56789]bsd*
mips-*-bsd* | mips-*-riscosbsd* | mips-*-riscos[1234]bsd*
mips-*-riscos[56789]sysv4*
mips-*-sysv4* | mips-*-riscos[1234]sysv4* | mips-*-riscossysv4
mips-*-riscos[56789]sysv*
mips-*-sysv* | mips-*-riscos*sysv
mips-*-riscos[56789]*
mips64orionel-*-elf*
mips64orion-*-elf*
mips64orion-*-rtems*

I'd like to get rid of:

mips-ecoff
mips-sgi-irix5
mips-sgi-irix5cross64

But I expect I'll get a lot of pushback on these. Even though sgi has
definitely EOL irix5. Years ago.

-eric

--
Written using state-of-the-rat
technology.
Zack Weinberg
2002-04-17 19:01:50 UTC
Permalink
On Tue, Apr 16, 2002 at 08:32:42PM -0700, Eric Christopher wrote:
> On Tue, 16 Apr 2002 10:04:45 -0700, Zack Weinberg wrote:
>
> > Here is my current list of targets to deprecate.
>
> And I'd like to add:

Thanks. I simplified your list a bit:

mips-sgi-irix[1234]*
mips-dec-*
mips-sony-*
mips-tandem-*
mips-*-ultrix*
mips-*-riscos*
mips-*-bsd*
mips-*-sysv*
mips64orion*-*-*

with -sni-sysv4 whitelisted. In the interest of avoiding controversy
in this cycle, let's leave that and irix5 for now.

zw
Eric Christopher
2002-04-17 19:14:54 UTC
Permalink
>
> with -sni-sysv4 whitelisted. In the interest of avoiding controversy
> in this cycle, let's leave that and irix5 for now.

OK. Thanks.

-eric

--
Written using state-of-the-rat
technology.
Joel Sherrill
2002-04-17 19:29:31 UTC
Permalink
Zack Weinberg wrote:
>
> On Tue, Apr 16, 2002 at 08:32:42PM -0700, Eric Christopher wrote:
> > On Tue, 16 Apr 2002 10:04:45 -0700, Zack Weinberg wrote:
> >
> > > Here is my current list of targets to deprecate.
> >
> > And I'd like to add:
>
> Thanks. I simplified your list a bit:
>
> mips-sgi-irix[1234]*
> mips-dec-*
> mips-sony-*
> mips-tandem-*
> mips-*-ultrix*
> mips-*-riscos*
> mips-*-bsd*
> mips-*-sysv*
> mips64orion*-*-*
>
> with -sni-sysv4 whitelisted. In the interest of avoiding controversy
> in this cycle, let's leave that and irix5 for now.

mips64orion*-*-rtems* still has users and I still build/run/report
test results on it on a regularly basis. In fact, see this
test result from 16 April 2002:

http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00587.html

> zw

--
Joel Sherrill, Ph.D. Director of Research & Development
***@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Eric Christopher
2002-04-17 19:31:20 UTC
Permalink
>
> mips64orion*-*-rtems* still has users and I still build/run/report
> test results on it on a regularly basis. In fact, see this
> test result from 16 April 2002:
>
> http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00587.html

Cool. As long as someone still cares about it and looks at it on a
regular basis... :)

-eric

--
Written using state-of-the-rat
technology.
Zack Weinberg
2002-04-17 19:34:24 UTC
Permalink
On Wed, Apr 17, 2002 at 02:29:31PM -0500, Joel Sherrill wrote:
>
> mips64orion*-*-rtems* still has users and I still build/run/report
> test results on it on a regularly basis. In fact, see this
> test result from 16 April 2002:

In that case it doesn't make much sense to drop the other orion
targets either. Removed from list.

zw
Dana, Eric
2002-04-17 15:02:16 UTC
Permalink
Eric,

My company is using Sinix:

mips-sni-sysv4

--Eric Dana--


-----Original Message-----
From: Eric Christopher [mailto:***@redhat.com]
Sent: Tuesday, April 16, 2002 11:33 PM
To: ***@gcc.gnu.org
Subject: Re: Obsolete configurations, round 3


On Tue, 16 Apr 2002 10:04:45 -0700, Zack Weinberg wrote:

> Here is my current list of targets to deprecate.

And I'd like to add:

mips-sni-sysv4
mips-sgi-irix4loser
mips-sgi-irix4
mips-sgi-irix[3..]
mips-dec-osfrose
mips-dec-osf
mips-dec-bsd
mips-sony-bsd* | mips-sony-newsos*
mips-sony-sysv
mips-tandem-sysv4
mips-*-ultrix* | mips-dec-mach3
mips-*-riscos[56789]bsd*
mips-*-bsd* | mips-*-riscosbsd* | mips-*-riscos[1234]bsd*
mips-*-riscos[56789]sysv4*
mips-*-sysv4* | mips-*-riscos[1234]sysv4* | mips-*-riscossysv4
mips-*-riscos[56789]sysv*
mips-*-sysv* | mips-*-riscos*sysv
mips-*-riscos[56789]*
mips64orionel-*-elf*
mips64orion-*-elf*
mips64orion-*-rtems*

I'd like to get rid of:

mips-ecoff
mips-sgi-irix5
mips-sgi-irix5cross64

But I expect I'll get a lot of pushback on these. Even though sgi has
definitely EOL irix5. Years ago.

-eric

--
Written using state-of-the-rat
technology.
Eric Christopher
2002-04-17 17:51:20 UTC
Permalink
On Wed, 2002-04-17 at 08:02, Dana, Eric wrote:
> Eric,
>
> My company is using Sinix:
>
> mips-sni-sysv4
>

Do you track gcc releases/need a new compiler? I have no earthly way of
making sure that this even builds let alone maintain it so someone else
would need to take over that responsibility if we keep the target.

-eric

--
Written using state-of-the-rat
technology.
Andi Kleen
2002-04-18 10:43:21 UTC
Permalink
Eric Christopher <***@redhat.com> writes:

> On Tue, 16 Apr 2002 10:04:45 -0700, Zack Weinberg wrote:
>
> > Here is my current list of targets to deprecate.
>
> And I'd like to add:
>
> mips-sni-sysv4

SINIX/MIPS (or "reliant unix") is still widely used and even new boxes are
still sold.

> mips-sgi-irix4loser
> mips-sgi-irix4

I at least used to have a irix4 box around. It was the last non bloated
stable irix before the 5.x range :-)

> mips-sony-bsd* | mips-sony-newsos*

Didn't the FSF have newsos boxes (may be wrong on that though)?

> mips-*-ultrix* | mips-dec-mach3

i'm pretty sure there are still ultrix boxes around and they are used.



-Andi
Eric Christopher
2002-04-18 18:24:36 UTC
Permalink
>
> i'm pretty sure there are still ultrix boxes around and they are used.

Like most of the ports that I wanted to get rid of, I'm sure that
someone, somewhere has one and is using it. The question is if they
really need that new compiler (my ultrix box as an example can't even
bootstrap gcc - not enough memory), and is it worth the effort to
continue to maintain the port with that sole user who never reports bugs
or tries to compile outside of releases.

I will keep SINIX if they really are still selling the things. I'm
amazed.

zack: can you please remove sinix from the list? thanks.

-eric

--
Written using state-of-the-rat
technology.
David Edelsohn
2002-05-08 20:36:49 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> MODE_BITSIZE (TYPE_MODE (wchar_type_node)) ? Only works if targtyps.c
Zack> is linked into the compiler proper, not one of the myriad Ada helper
Zack> utilities.

It is not linked into the compiler proper. We already went
through this problem with

#define WIDEST_HARDWARE_FP_SIZE LONG_DOUBLE_TYPE_SIZE

requiring target_flags.

David
David Edelsohn
2002-05-26 18:07:14 UTC
Permalink
What about Stephen's concern that the changes were made without a
plan for FP correctness? The work had a plan for simplification and
consistency in the compiler, which is very helpful. Where was volunteer
expertise in compiler FP numerical analysis taken into account?

David
David Edelsohn
2002-08-07 19:31:05 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> This test is for a bug in the Fortran I/O library, which has been
Zack> there for at least as long as the Fortran compiler has been part of
Zack> the official source tree, and is not easy to fix (the relevant code
Zack> being a pile of spaghetti and action at a distance). Can we mark it
Zack> XFAIL?

Toon has said that he has been delaying debugging this until GCC
3.3 enters Stage 3 development because he wanted to concentrate on new
features and functionality during the GCC development cycle. On when the
entire project enters Stage 3 do some developers consider it productive to
work on bug fixing. Otherwise they may lose the opportunity to finish
other projects in time for the next release.

David
David Edelsohn
2002-09-18 03:15:48 UTC
Permalink
I have been bootstrapping with GCC 2.95.4 and AIX assembler. I am
starting a bootstrap with GCC 3.0.3. Maybe this is a GCC 2.9x
miscompilation.

David
David Edelsohn
2002-10-19 01:46:02 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> The i370 and s390 targets are for the same architecture. They are not
Zack> entirely redundant; each supports operating environments that the
Zack> other doesn't. However, the s390 target is actively maintained, the
Zack> i370 isn't, and HOST_EBCDIC doesn't really work. I would like to
Zack> suggest, therefore, that we drop (a) the i370, and (b) any pretense of
Zack> supporting EBCDIC as the primary character encoding for the host. (It
Zack> is much, much easier to support it in the target.)

The i370 port still is used for z/OS (aka OS/390 aka MVS) Unix
System Services. I am not sure which port was used as the basis for the
TPF work which eventually should be merged into the FSF sources.

Zack> rs6000-ibm-aix[123]*
Zack> rs6000-ibm-aix4* # maybe

Huh? It takes incrementally minimal effort to keep older AIX
configurations around and AIX 4.3 still is in wide-spread use.

David
David Edelsohn
2002-12-13 15:34:42 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> This is my updated list of targets to be deprecated in 3.3 and removed
Zack> in 3.4. It's exhaustive - if there's something currently listed in
Zack> mainline config.gcc as deprecated but not on that list, it's been
Zack> reprieved.

Zack> i370-*-*

Again, please do not remove this target. Dave Pitt and others
continue to work on it.

Thanks, David
David Edelsohn
2002-12-14 04:07:04 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> I'd like to merge the basic-improvements-branch back to the mainline
Zack> immediately after the 3.3 branch is created. Can we please extend the
Zack> 'no checkins' window past the creation of the branch for as long as it
Zack> will take me to do that? This will be no more than four hours,
Zack> assuming nothing breaks, and you create the branch at a time when I'll
Zack> be awake for the four hours immediately following. Most of that time
Zack> will be spent running two bootstraps, one of the mainline at the 3.3
Zack> branch point, one of the merged tree.

If the 3.4BIB changes still produce the regressions which I and
others have reported in the past few days, I immediately will request that
the breakage be fixed or reverted within 48 hours as required by the GCC
Development Plan Patch Reversion policy. Creating the GCC 3.3 branch does
not remove the requirement that the GCC sources remain usable for everyone
to do development.

David
David Edelsohn
2002-12-14 04:08:22 UTC
Permalink
>>>>> Zack Weinberg writes:

>> Does it have the necessary builds & tests on three platforms?

Zack> Not yet - the merged tree doesn't exist yet. I can arrange testing on
Zack> two platforms (although this will take longer than four hours); I'd
Zack> need a volunteer for the third. I don't want to keep the tree locked
Zack> for too long, but I'm also worried about merge conflicts if people
Zack> start checking in dev-stage-1 stuff on the mainline before
Zack> basic-improvements is merged back. Ideas?

Then maybe Mark should have delayed the GCC 3.3 branch until
3.4BIB was safe and ready for merging.

David
Mark Mitchell
2002-12-14 04:15:16 UTC
Permalink
The commands to create the branch are running. I won't get to all of
the steps in branching.html today; that will happen tomorrow.

Per Zack's request, the mainline is now under his control. Zack will
merge the basic-improvements branch to the mainline and ensure all is
well, and then send out a message announcing that. If Zack's still at
work, that might happen tonight; otherwise, it will happen later.
Zack, the world will keep spinning if this takes a while; don't kill
yourself getting it done. :-)

Until Zack gives the OK, the mainline is still frozen. Once Zack
gives the OK, the mainline is open under the usual rules: all approved
patches are OK, if they don't cause regressions. I'd prefer that we
phase in the merging of any major branches, rather than trying to do
that all at once; let's coordinate that by announcing the intention to
merge a branch at least 24 hours in advance of the actual merge, and
avoid doing more than one within a couple of days of each other.

Zack, it may take a few minutes for the "cvs rtag" commands to run
through. Once you see "gcc-3_3-branch" tags on files, it's done.

Thanks,

--
Mark Mitchell ***@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
David Edelsohn
2002-12-16 22:12:57 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> David Edelsohn <***@watson.ibm.com> writes:
>> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
>>
>> (float) sin(x)
>>
>> as
>>
>> sinf(x)?

Zack> I remember such an optimization being implemented but I can't find the
Zack> change log entry for it. My recollection is that it was Jan Hubicka
Zack> who coded it. Jan?

Yes, it appears to be due to the builtins.def changes by Jan which
assumes that all of those functions natively are available on every
target. One cannot make that assumption. Testing for the existence of
those functions on the target is not easy.

In most cases, the transformation will result in a linker error on
systems which do not provide the function, but libstdc++-v3 graciously
provides the symbols, creating a recursion in those definitions.

David
Gabriel Dos Reis
2002-12-17 08:37:04 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

| >>>>> Zack Weinberg writes:
|
| Zack> David Edelsohn <***@watson.ibm.com> writes:
| >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
| >>
| >> (float) sin(x)
| >>
| >> as
| >>
| >> sinf(x)?
|
| Zack> I remember such an optimization being implemented but I can't find the
| Zack> change log entry for it. My recollection is that it was Jan Hubicka
| Zack> who coded it. Jan?
|
| Yes, it appears to be due to the builtins.def changes by Jan which
| assumes that all of those functions natively are available on every
| target. One cannot make that assumption. Testing for the existence of
| those functions on the target is not easy.

I think this is a case where GCC's logic in apply transformations just
breaks down.

| In most cases, the transformation will result in a linker error on
| systems which do not provide the function, but libstdc++-v3 graciously
| provides the symbols, creating a recursion in those definitions.

I don't think libstdc++-v3 is at fault here. I think it is the
middle-end. That is, if as a programmer, I do know that the target is
lacking sinf() and consciously I did write "(float) sin(x)", then I
find it a diservice that GCC calls a sinf(). Really.

I see values for the mentioned transformation. But bindly applying it
is a -not- a service.

-- Gaby
Jan Hubicka
2002-12-17 08:50:43 UTC
Permalink
> David Edelsohn <***@watson.ibm.com> writes:
>
> | >>>>> Zack Weinberg writes:
> |
> | Zack> David Edelsohn <***@watson.ibm.com> writes:
> | >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
> | >>
> | >> (float) sin(x)
> | >>
> | >> as
> | >>
> | >> sinf(x)?
> |
> | Zack> I remember such an optimization being implemented but I can't find the
> | Zack> change log entry for it. My recollection is that it was Jan Hubicka
> | Zack> who coded it. Jan?
> |
> | Yes, it appears to be due to the builtins.def changes by Jan which
> | assumes that all of those functions natively are available on every
> | target. One cannot make that assumption. Testing for the existence of
> | those functions on the target is not easy.
>
> I think this is a case where GCC's logic in apply transformations just
> breaks down.
>
> | In most cases, the transformation will result in a linker error on
> | systems which do not provide the function, but libstdc++-v3 graciously
> | provides the symbols, creating a recursion in those definitions.
>
> I don't think libstdc++-v3 is at fault here. I think it is the
> middle-end. That is, if as a programmer, I do know that the target is
> lacking sinf() and consciously I did write "(float) sin(x)", then I
> find it a diservice that GCC calls a sinf(). Really.

Yes, I see that.
But it is really not different from reusing memset() call for totally
different purpose. You function is not valid C so it should use
-fdisable-builtins.
>
> I see values for the mentioned transformation. But bindly applying it
> is a -not- a service.
In what conditions do you think we should apply that?

Honza
>
> -- Gaby
Gabriel Dos Reis
2002-12-17 09:06:50 UTC
Permalink
Jan Hubicka <***@suse.cz> writes:

| > David Edelsohn <***@watson.ibm.com> writes:
| >
| > | >>>>> Zack Weinberg writes:
| > |
| > | Zack> David Edelsohn <***@watson.ibm.com> writes:
| > | >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
| > | >>
| > | >> (float) sin(x)
| > | >>
| > | >> as
| > | >>
| > | >> sinf(x)?
| > |
| > | Zack> I remember such an optimization being implemented but I can't find the
| > | Zack> change log entry for it. My recollection is that it was Jan Hubicka
| > | Zack> who coded it. Jan?
| > |
| > | Yes, it appears to be due to the builtins.def changes by Jan which
| > | assumes that all of those functions natively are available on every
| > | target. One cannot make that assumption. Testing for the existence of
| > | those functions on the target is not easy.
| >
| > I think this is a case where GCC's logic in apply transformations just
| > breaks down.
| >
| > | In most cases, the transformation will result in a linker error on
| > | systems which do not provide the function, but libstdc++-v3 graciously
| > | provides the symbols, creating a recursion in those definitions.
| >
| > I don't think libstdc++-v3 is at fault here. I think it is the
| > middle-end. That is, if as a programmer, I do know that the target is
| > lacking sinf() and consciously I did write "(float) sin(x)", then I
| > find it a diservice that GCC calls a sinf(). Really.
|
| Yes, I see that.
| But it is really not different from reusing memset() call for totally
| different purpose. You function is not valid C so it should use
| -fdisable-builtins.

Which function is not valid C?

Please, do remember that libtdc++-v3 is part of the compiler runtime
support, so your argument that it is not valid is pointless.

| > I see values for the mentioned transformation. But bindly applying it
| > is a -not- a service.
| In what conditions do you think we should apply that?

There ought to be a switch to tell the compiler which functions not to
use its transformations.

-- Gaby
David Edelsohn
2003-01-12 20:33:55 UTC
Permalink
Instead of declaring the variable with a mode, could you use the
GCC local register variable extension associating the variable with
register cr0?

The more general case is something that John Carr once mentioned
and is recommended by IBM for compiler implementations: use PowerPC
condition registers for booleans and small bitfields. Instead of
comparing the bitfield with a mask, reload the value into a condition
register and synthesize the appropriate type of comparison operator to
test the bits of interest directly.

David
Zack Weinberg
2003-01-12 21:00:21 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

> Instead of declaring the variable with a mode, could you use
> the GCC local register variable extension associating the variable
> with register cr0?

I tried that and got "invalid asm() declaration" and/or
"unrecognizable insn" errors.

> The more general case is something that John Carr once
> mentioned and is recommended by IBM for compiler implementations:
> use PowerPC condition registers for booleans and small bitfields.
> Instead of comparing the bitfield with a mask, reload the value into
> a condition register and synthesize the appropriate type of
> comparison operator to test the bits of interest directly.

In theory this should be doable right now for booleans by writing
BImode patterns in rs6000.md, though I'm not sure if the optimizer
will pick up on that. Small bitfields would be trickier. We don't
really have a way to represent "this register can hold values in the
range 0-15" as far as I know.

zw
David Edelsohn
2003-02-19 01:04:17 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> so you can see that not only is the loop still present, but the memory
Zack> write has not been sunk.

Which is why I am eager to fix store motion utilizing Zdenek and
Daniel Berlin's efforts.

David
David Edelsohn
2003-02-24 16:12:29 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> I'm pushing back on the following:

Zack> i370-*-*

Again, no. There are people using this port that cannot use the
S/390 port. The two ports are not equivalent -- both in architectures
supported and in OSes supported.

David
Andreas Jaeger
2003-02-24 16:14:25 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

>>>>>> Zack Weinberg writes:
>
> Zack> I'm pushing back on the following:
>
> Zack> i370-*-*
>
> Again, no. There are people using this port that cannot use the
> S/390 port. The two ports are not equivalent -- both in architectures
> supported and in OSes supported.

Is i370 actually working? I remembered that the port was never finished,

Andreas
--
Andreas Jaeger
SuSE Labs ***@suse.de
private ***@arthur.inka.de
http://www.suse.de/~aj
Zack Weinberg
2003-02-24 17:15:15 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

>>>>>> Zack Weinberg writes:
>
> Zack> I'm pushing back on the following:
>
> Zack> i370-*-*
>
> Again, no. There are people using this port that cannot use the
> S/390 port. The two ports are not equivalent -- both in architectures
> supported and in OSes supported.

Please explain why the architectures and OSes supported by i370 but
not s390 cannot be migrated to the s390 back end.

Also, since no one is is actively maintaining this port in the FSF
repository, and it has some serious issues there, I can only assume
that the people using this port are maintaining it in a private tree;
please explain why it affects that tree in any way if we drop the port
from the FSF repository.

zw
David Edelsohn
2003-02-24 17:48:20 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> Please explain why the architectures and OSes supported by i370 but
Zack> not s390 cannot be migrated to the s390 back end.

The IBM S/390 architecture added instructions which do not exist
in the S/370 architecture, including PC-relative addressing. The s390
port relies on and assumes those instructions for its addressing model.
The s390 port targets ELF and Linux.

Zack> Also, since no one is is actively maintaining this port in the FSF
Zack> repository, and it has some serious issues there, I can only assume
Zack> that the people using this port are maintaining it in a private tree;
Zack> please explain why it affects that tree in any way if we drop the port
Zack> from the FSF repository.

Red Hat delivered a GCC port for the mainframe TPF environment
which should be merged into the FSF sources.

David
Zack Weinberg
2003-02-24 18:10:50 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

>>>>>> Zack Weinberg writes:
>
> Zack> Please explain why the architectures and OSes supported by i370 but
> Zack> not s390 cannot be migrated to the s390 back end.
>
> The IBM S/390 architecture added instructions which do not exist
> in the S/370 architecture, including PC-relative addressing. The s390
> port relies on and assumes those instructions for its addressing model.

There is no intrinsic reason why the s390 port could not be modified
to support the older addressing models as well. I recognize that this
might be a substantial amount of effort.

> Red Hat delivered a GCC port for the mainframe TPF environment
> which should be merged into the FSF sources.

But they have not bothered to do so, nor am I particularly interested
in badgering them.

It is clear at this point that neither of us will convince the other
to change his position. Therefore I am requesting the Steering
Committee to make a decision on this issue.

zw
Gabriel Dos Reis
2003-02-24 18:42:42 UTC
Permalink
Zack Weinberg <***@codesourcery.com> writes:

[...]

| > Red Hat delivered a GCC port for the mainframe TPF environment
| > which should be merged into the FSF sources.
|
| But they have not bothered to do so, nor am I particularly interested
| in badgering them.
|
| It is clear at this point that neither of us will convince the other
| to change his position. Therefore I am requesting the Steering
| Committee to make a decision on this issue.

I hope we won't see so much rigid position in the future regarding
target deperacation. Why is it so urgent to deprecate that target
-now-?

-- Gaby
Zack Weinberg
2003-02-24 18:56:57 UTC
Permalink
Gabriel Dos Reis <***@integrable-solutions.net> writes:

> Zack Weinberg <***@codesourcery.com> writes:
> | It is clear at this point that neither of us will convince the other
> | to change his position. Therefore I am requesting the Steering
> | Committee to make a decision on this issue.
>
> I hope we won't see so much rigid position in the future regarding
> target deperacation. Why is it so urgent to deprecate that target
> -now-?

HOST_EBCDIC presents a severe hindrance to implementing multi-charset
support in a C99 compliant manner.

zw
Gabriel Dos Reis
2003-02-24 19:34:18 UTC
Permalink
Zack Weinberg <***@codesourcery.com> writes:

| Gabriel Dos Reis <***@integrable-solutions.net> writes:
|
| > Zack Weinberg <***@codesourcery.com> writes:
| > | It is clear at this point that neither of us will convince the other
| > | to change his position. Therefore I am requesting the Steering
| > | Committee to make a decision on this issue.
| >
| > I hope we won't see so much rigid position in the future regarding
| > target deperacation. Why is it so urgent to deprecate that target
| > -now-?
|
| HOST_EBCDIC presents a severe hindrance to implementing multi-charset
| support in a C99 compliant manner.

Then I would suggest we figure out ways to implement C99 compliant
multi-charset without insisting on deprecating that target (or more
accurately non-HOST_EBCDIC targets) now. The point is being a little
bit more flexible. Does that make sense?

-- Gaby
David Edelsohn
2003-02-24 19:56:03 UTC
Permalink
>>>>> Zack Weinberg writes:

>> I hope we won't see so much rigid position in the future regarding
>> target deperacation. Why is it so urgent to deprecate that target
>> -now-?

Zack> HOST_EBCDIC presents a severe hindrance to implementing multi-charset
Zack> support in a C99 compliant manner.

[This motivation should have been disclosed at the beginning of
the discussion.]

Is it possible to implement the multi-charset support and say that
HOST_EBCDIC will not be C99 compliant?

Thanks, David
Gabriel Dos Reis
2003-02-24 20:02:39 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

| Is it possible to implement the multi-charset support and say that
| HOST_EBCDIC will not be C99 compliant?

The reason I would suggest we find a positive answer to this question
is that not just because we claim to support C99 should mean that we
should abandon target on which we supported C90 because C90 will still
be around for at least another decaee.

-- Gaby
Zack Weinberg
2003-02-24 21:00:36 UTC
Permalink
David Edelsohn <***@watson.ibm.com> writes:

>>>>>> Zack Weinberg writes:
>
>>> I hope we won't see so much rigid position in the future regarding
>>> target deperacation. Why is it so urgent to deprecate that target
>>> -now-?
>
> Zack> HOST_EBCDIC presents a severe hindrance to implementing multi-charset
> Zack> support in a C99 compliant manner.
>
> [This motivation should have been disclosed at the beginning
> of the discussion.]

It was. If you reread my original message you will see a long
paragraph about HOST_EBCDIC.

> Is it possible to implement the multi-charset support and say
> that HOST_EBCDIC will not be C99 compliant?

Maybe, at a cost in maintainability, which would not be as extreme as
the cost to maintainability from supporting C99 under HOST_EBCDIC.

Let me go over the problem in some detail. C99 §6.4.3 defines
universal character names, \uXXXX or \UXXXXXXXX (where each X is a
hexadecimal digit), which may appear in identifiers, character
constants, and string literals, "to designate characters that are not
in the basic character set." The constraints and semantics of these
are defined in terms of ISO/IEC 10646 (Unicode) which is a superset of
ASCII. An implementation is allowed to accept "multibyte characters
that are not part of the basic source character set" in the same
contexts where UCNs are acceptable; if so, there shall be a (possibly
many-to-one) function mapping such characters to UCNs and therefore to
ISO10646 code points.

The most straightforward way to implement this functionality is to do
all internal processing of characters in an encoding of ISO10646.
Whatever the input character set actually is, it is transformed by
iconv() or similar utility into such an encoding (probably UTF8) in
translation phase 1. UCNs are replaced with the codepoints they
designate in phase 3. Finally, in phase 5, iconv() is again employed
to convert to the user- or locale-selected execution character set,
which is not necessarily Unicode.

Now, cpplib, c-lex.c, and c-parse.in all make extensive use of
character constants to designate members of the basic source character
set. The actual values of these constants are defined by the
execution character set of the host compiler. If that set is ASCII or
any superset thereof, there is no problem -- ASCII corresponds exactly
to the portion of ISO10646 containing the basic source character set.
But if the execution character set of the host compiler is EBCDIC,
the character constants will have inappropriate values for working
with text encoded in UTF8.

There are four possible ways to get around this problem:

- Replace all these character constants with integer or enumeration
constants. I consider this infeasible, it would make these parts of
the compiler much harder to maintain.

- Under HOST_EBCDIC, use an internal encoding where members of the
basic source character set have their EBCDIC values. UTF-EBCDIC is
such an encoding, but it is not supported by GNU iconv; it would
have to be implemented, and appropriate #ifdeffage added to cpplib,
with consonant (moderate) maintenance burden.

- Under HOST_EBCDIC disallow UCNs and use of extended character sets,
claiming only C90 compliance. This is doable at roughly the same
maintenance burden as option two: a certain amount of #ifdeffage and
rarely-tested code paths in cpplib.

- Abandon HOST_EBCDIC: require that GCC be built in an environment
where the execution character set of the host compiler is ASCII or a
superset thereof. This does /not/ entail that GCC would be unable
to accept input encoded in EBCDIC or use EBCDIC for its own
execution character set; in fact both are quite easy to accomplish,
by the aforementioned transformations in phases 1 and 5.

Obviously I am in favor of option four.

It turns out that only a small part of the i370 back end is dependent
on HOST_EBCDIC. I would be willing to compromise at the removal of
all support for this mode, leaving the rest of the back end intact.
However, I think that the demonstrated lack of interest in maintaining
the port in the FSF repository is still a strong argument for
obsoleting this entire back end.

zw
Fergus Henderson
2003-02-25 03:05:56 UTC
Permalink
On 24-Feb-2003, Zack Weinberg <***@codesourcery.com> wrote:
> There are four possible ways to get around this problem:
>
> - Replace all these character constants with integer or enumeration
> constants. I consider this infeasible, it would make these parts of
> the compiler much harder to maintain.

Well, sure, don't use integer constants directly, use #defines!

I don't see why e.g.

if (c == SLASH_CHAR)

is so much harder to maintain than

if (c == '/')

--
Fergus Henderson <***@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Nick Ing-Simmons
2003-04-14 16:35:35 UTC
Permalink
Fergus Henderson <***@cs.mu.OZ.AU> writes:
>On 24-Feb-2003, Zack Weinberg <***@codesourcery.com> wrote:
>> There are four possible ways to get around this problem:
>>
>> - Replace all these character constants with integer or enumeration
>> constants. I consider this infeasible, it would make these parts of
>> the compiler much harder to maintain.

The UTF-EBCDIC scheme avoids this problem.
(perl uses UTF-EBCDIC on OS390.)

>
>Well, sure, don't use integer constants directly, use #defines!
>
>I don't see why e.g.
>
> if (c == SLASH_CHAR)
>
>is so much harder to maintain than
>
> if (c == '/')
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
David Edelsohn
2003-02-24 21:36:44 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> It turns out that only a small part of the i370 back end is dependent
Zack> on HOST_EBCDIC. I would be willing to compromise at the removal of
Zack> all support for this mode, leaving the rest of the back end intact.
Zack> However, I think that the demonstrated lack of interest in maintaining
Zack> the port in the FSF repository is still a strong argument for
Zack> obsoleting this entire back end.

The main use of the i370 port is z/OS Unix System Services, which
is an EBCDIC environment. If GCC cannot be hosted in an EBCDIC
environment, the i370 port is much less useful, so your compromise is not
much of a compromise at all.

David
Mark Mitchell
2003-02-24 22:48:23 UTC
Permalink
On Mon, 2003-02-24 at 13:36, David Edelsohn wrote:
> >>>>> Zack Weinberg writes:
>
> Zack> It turns out that only a small part of the i370 back end is dependent
> Zack> on HOST_EBCDIC. I would be willing to compromise at the removal of
> Zack> all support for this mode, leaving the rest of the back end intact.
> Zack> However, I think that the demonstrated lack of interest in maintaining
> Zack> the port in the FSF repository is still a strong argument for
> Zack> obsoleting this entire back end.
>
> The main use of the i370 port is z/OS Unix System Services, which
> is an EBCDIC environment. If GCC cannot be hosted in an EBCDIC
> environment, the i370 port is much less useful, so your compromise is not
> much of a compromise at all.
>
> David

I think that i370 is clearly useful to people and should be supported.

The question is how to do that. Ideally, I agree with Zack that it
should be merged with the s390 backend; the architectures are similar
enough that they should be one backend.

However, I don't think we can deprecate i370 to try to force that issue;
we have to hope that someone will actually go it. And if they did do
it, I think we'd still have the EBCDIC issue -- that's part of the OS.

How exactly does the EBCDIC stuff interact with the multi-charset stuff?

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Daniel Jacobowitz
2003-02-24 22:55:39 UTC
Permalink
On Mon, Feb 24, 2003 at 02:48:23PM -0800, Mark Mitchell wrote:
> On Mon, 2003-02-24 at 13:36, David Edelsohn wrote:
> > >>>>> Zack Weinberg writes:
> >
> > Zack> It turns out that only a small part of the i370 back end is dependent
> > Zack> on HOST_EBCDIC. I would be willing to compromise at the removal of
> > Zack> all support for this mode, leaving the rest of the back end intact.
> > Zack> However, I think that the demonstrated lack of interest in maintaining
> > Zack> the port in the FSF repository is still a strong argument for
> > Zack> obsoleting this entire back end.
> >
> > The main use of the i370 port is z/OS Unix System Services, which
> > is an EBCDIC environment. If GCC cannot be hosted in an EBCDIC
> > environment, the i370 port is much less useful, so your compromise is not
> > much of a compromise at all.
> >
> > David
>
> I think that i370 is clearly useful to people and should be supported.
>
> The question is how to do that. Ideally, I agree with Zack that it
> should be merged with the s390 backend; the architectures are similar
> enough that they should be one backend.
>
> However, I don't think we can deprecate i370 to try to force that issue;
> we have to hope that someone will actually go it. And if they did do
> it, I think we'd still have the EBCDIC issue -- that's part of the OS.
>
> How exactly does the EBCDIC stuff interact with the multi-charset stuff?

I'm concerned that we're keeping support for the i370 based on some
work David says Red Hat has done on the port, which is not in the tree.
I seem to recall messages to the effect of "the i370 port in FSF GCC
does not work, but there's this code in Red Hat somewhere that does";
my apologies if I'm misinterpreting someone.

If that's right I don't think we should be talking about preserving the
current i370 port unless that work is contributed.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Zack Weinberg
2003-02-24 23:17:30 UTC
Permalink
Mark Mitchell <***@codesourcery.com> writes:

> I think that i370 is clearly useful to people and should be supported.
>
> The question is how to do that. Ideally, I agree with Zack that it
> should be merged with the s390 backend; the architectures are similar
> enough that they should be one backend.
>
> However, I don't think we can deprecate i370 to try to force that issue;
> we have to hope that someone will actually go it. And if they did do
> it, I think we'd still have the EBCDIC issue -- that's part of the OS.
>
> How exactly does the EBCDIC stuff interact with the multi-charset stuff?

See my other message, the one David is quoting.

I've said all I have to say on the subject. Let the SC make a
decision, and I'll abide by it.

zw
David Edelsohn
2003-02-24 23:12:23 UTC
Permalink
>>>>> Daniel Jacobowitz writes:

> I'm concerned that we're keeping support for the i370 based on some
> work David says Red Hat has done on the port, which is not in the tree.
> I seem to recall messages to the effect of "the i370 port in FSF GCC
> does not work, but there's this code in Red Hat somewhere that does";
> my apologies if I'm misinterpreting someone.

The Red Hat work apparently was based on the s390 port, not the
i370 port, but there are people who use and maintain the i370 port.

As I mentioned in my previous reply, Dave Pitts would try to
maintain the i370 port if we were not making the process so difficult.

David
Steven Bosscher
2003-02-24 23:23:08 UTC
Permalink
Op di 25-02-2003, om 00:12 schreef David Edelsohn:
> >>>>> Daniel Jacobowitz writes:
>
> > I'm concerned that we're keeping support for the i370 based on some
> > work David says Red Hat has done on the port, which is not in the tree.
> > I seem to recall messages to the effect of "the i370 port in FSF GCC
> > does not work, but there's this code in Red Hat somewhere that does";
> > my apologies if I'm misinterpreting someone.
>
> The Red Hat work apparently was based on the s390 port, not the
> i370 port, but there are people who use and maintain the i370 port.
>
> As I mentioned in my previous reply, Dave Pitts would try to
> maintain the i370 port if we were not making the process so difficult.

Well that's quite a choice, eh? Making it easier to maintain a _single_
HOST_EBCDIC port of relatively minor importance (no offense), at the
cost of making it harder to maintain C99 support for literaly _all_
other ports...

Greetz
Steven
Tolga Dalman
2003-02-25 03:25:25 UTC
Permalink
On Mon, 24 Feb 2003 19:51:17 -0500 David Edelsohn <***@watson.ibm.com> wrote:

> >>>>> Steven Bosscher writes:
>
> Steven> Well that's quite a choice, eh? Making it easier to maintain a _single_
> Steven> HOST_EBCDIC port of relatively minor importance (no offense), at the
> Steven> cost of making it harder to maintain C99 support for literaly _all_
> Steven> other ports...
>
> Maybe you should remind yourself of GCC's Mission Statement:
>
> GCC development is a part of the GNU Project, aiming to improve the
> compiler used in the GNU system including the GNU/Linux variant. The GCC
> development effort uses an open development environment and supports many
> other platforms in order to foster a world-class optimizing compiler, to
> attract a larger team of developers, to ensure that GCC and the GNU system
> work on multiple architectures and diverse environments, and to more
> thoroughly test and extend the features of GCC.
>
>
> We have motivation to support non-GNU, non-Unix, non-ASCII platforms. If
> we decide that an existing, working, useful target is expendible, where
> does it end?
>

i totally agree to you, but is that all the effort worth? the consequence would
be (probably) worse code, more bugs to care about and for sure more work.

just my 2 cents.
Tolga Dalman.
Richard Henderson
2003-02-25 23:55:18 UTC
Permalink
On Mon, Feb 24, 2003 at 06:12:23PM -0500, David Edelsohn wrote:
> As I mentioned in my previous reply, Dave Pitts would try to
> maintain the i370 port if we were not making the process so difficult.

In what way are we making the process difficult?

The last message I see from dpitts on _any_ subject
dates from November 2002, and before that August.


r~
Nathanael Nerode
2003-02-25 08:42:13 UTC
Permalink
>Now, cpplib, c-lex.c, and c-parse.in all make extensive use of
>character constants to designate members of the basic source character
>set. The actual values of these constants are defined by the
>execution character set of the host compiler. If that set is ASCII or
This sounds wrong. Shouldn't the values be defined by the execution set
of the *build* compiler? In a Canadian cross, that should be the
compiler which is used to compile these files.

>any superset thereof, there is no problem -- ASCII corresponds exactly
>to the portion of ISO10646 containing the basic source character set.
>But if the execution character set of the host compiler is EBCDIC,
>the character constants will have inappropriate values for working
>with text encoded in UTF8.

Again, *build* compiler. I suspect HOST_EBCDIC may be misnamed.

Suppose we require that the *build* compiler work in ASCII, and require
that GCC operate in an encoding of ISO10646 internally. We can then
still make a native GCC for an EBCDIC host by causing all files input to
be translated from EBCDIC to ISO10646 before the rest of GCC operates,
and likewise on output. However, this native GCC can't be *built* on an
EBCDIC machine; it has to be built on an ASCII machine.

In other words, you can make GCC target EBCDIC machines, you can have
EBCDIC machines as hosts running GCC, but you can't actually build GCC
on an EBCDIC machine.

I think that's a reasonable, low-gunk solution. Are the users of EBCDIC
environments wedded to the ability to bootstrap on their machines, or
would being able to run GCC (built elsewhere) on their machines be
sufficient?

--Nathanael
David Edelsohn
2003-02-25 17:50:52 UTC
Permalink
>>>>> Nathanael Nerode writes:

Nathanael> In other words, you can make GCC target EBCDIC machines, you can have
Nathanael> EBCDIC machines as hosts running GCC, but you can't actually build GCC
Nathanael> on an EBCDIC machine.

GCC for z/OS Unix System Services uses the system assembler and
linker to build other applications and to build itself. GNU Binutils does
not exist for z/OS to provide a Free Software cross-environment. The only
cross-environment is the commercial Dignus product.

Developers use gcc-i370 both natively on z/OS and with the Dignus
System/ASM cross-assembler environment.

David
Nathanael Nerode
2003-02-25 18:13:54 UTC
Permalink
David Edelsohn wrote:
>>>>>>Nathanael Nerode writes:
>
>
> Nathanael> In other words, you can make GCC target EBCDIC machines, you can have
> Nathanael> EBCDIC machines as hosts running GCC, but you can't actually build GCC
> Nathanael> on an EBCDIC machine.
>
> GCC for z/OS Unix System Services uses the system assembler and
> linker to build other applications and to build itself. GNU Binutils does
> not exist for z/OS to provide a Free Software cross-environment. The only
> cross-environment is the commercial Dignus product.
Hmm. So with my proposal you'd have to use Dingus to build GCC, and
could then use GCC natively on z/OS. I take it you're saying that would
not be a good situation. OK, just getting things clear.

... Actually, I'm not clear on when character constants like '/' are
converted to numbers. Does the *compiler* do it or does the
*assembler*? If the compiler does it, one could theoretically
cross-compile the relevant GCC files to assembly (on an ASCII machine),
move everything over to the EBCDIC machine, and do the rest of the build
there (being careful not to recompile those files). This would require
a bit of care... maybe too ugly to consider.

> Developers use gcc-i370 both natively on z/OS and with the Dignus
> System/ASM cross-assembler environment.
>
> David
>
David Edelsohn
2003-03-22 06:21:20 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> However, it is likely to be addressed by completing the store-motion
Zack> pass, which has never worked properly. If you would like to help with
Zack> that, talk to Daniel Berlin (cc:ed).

I believe that Zdenek has a revised store-motion patch which has
been waiting for approval.

David
David Edelsohn
2003-04-07 20:48:10 UTC
Permalink
>>>>> Zack Weinberg writes:

Zack> I have an emacs write-contents-hook for change logs which
Zack> canonicalizes the whole file on the new date format. This was an
Zack> experiment and if people don't like it I'll stop using it.

Please do not change past ChangeLog entries and please correct the
files you already have changed. This is not a change that you
unilaterally should decide.

David
David Edelsohn
2003-04-10 20:32:07 UTC
Permalink
>>>>> Nathanael Nerode writes:

Nathanael> * Show-stoppers: must be fixed before release, regardless of difficulty *

Nathanael> Wrong code bugs:
Nathanael> 9745 alias problem during loop pass (powerpc)

Developing an effective solution to this bug report is proving
very difficult. It appeared when David Miller removed SEQUENCE rtl,
exposing some sort of latent bug. Pessimizing all frame pointer
references will prevent GCC from achieving its performance requirements
necessary for the release to proceed.

Reverting the SEQUENCE rtl removal patch is impossible. Teaching
GCC's current alias analysis infrastructure how to handle a non-fixed
frame pointer is proving equally difficult.

We might be able to re-introduce the implicit restriction imposed
by SEQUENCE which allowed the specific testcase to work, but an alias
analysis flaw will remain.

David
Mark Mitchell
2003-04-10 21:29:17 UTC
Permalink
> Developing an effective solution to this bug report is proving
> very difficult. It appeared when David Miller removed SEQUENCE rtl,
> exposing some sort of latent bug. Pessimizing all frame pointer
> references will prevent GCC from achieving its performance requirements
> necessary for the release to proceed.

We're going to have to:

(a) Release with the pessimistic version, maybe under #ifdef
__powerpc__.

(b) Live with the codegen bug.

(c) Fix the bug.

(d) Make no more GCC releases ever.

I'm not very happy with (d).

I think that, due to the fact you site (like that there is no easy patch
to revert), we're going to have to choose between (a), (b), and (c).

Since (c) is a non-trivial choice (someone has to do work and/or spend
money), I don't think we can just say "well, we'll fix it."

David, I suggest that you indicate whether (a) or (b) is better from
your point of view, as a fallback. At the same time, I'd suggest you
continue working on (c).

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Wolfgang Bangerth
2003-04-10 22:02:14 UTC
Permalink
Can I lobby a little for c++/9393? I only rediscovered this these days, so
I doubt anyone has looked at it with an angle on 3.3 (because it didn't
have priority "high" until very recently). It's
- a problem that one cannot work around
- generates code that cannot be linked
- violates the C++ standard
- a regression against 2.95
- breaks my application and prevents Brad from running it on his system :-)

(In short: members of anonymous namespaces only get mangled names that
depend on the file name, nothing else. If you compile the same file twice
with different flags, then link them together, you'll get linker errors
about duplicate symbols for all members of anonymous namespaces in this
file.)

W.

-------------------------------------------------------------------------
Wolfgang Bangerth email: ***@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
Mark Mitchell
2003-04-10 22:16:18 UTC
Permalink
On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
>
> Can I lobby a little for c++/9393? I only rediscovered this these days, so
> I doubt anyone has looked at it with an angle on 3.3 (because it didn't
> have priority "high" until very recently). It's
> - a problem that one cannot work around
> - generates code that cannot be linked
> - violates the C++ standard
> - a regression against 2.95
> - breaks my application and prevents Brad from running it on his system :-)

We've already fought about this one. :-) See my "Release-Note" there.

This one can't be fixed in the 3.3 time frame, I don't think.

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Wolfgang Bangerth
2003-04-10 22:23:07 UTC
Permalink
> > Can I lobby a little for c++/9393? I only rediscovered this these days, so
>
> We've already fought about this one. :-) See my "Release-Note" there.

Ah, sorry about that. I just missed it. I'll downgrade the priority then
again.


> This one can't be fixed in the 3.3 time frame, I don't think.

Too bad. Do I get from your explanation in the PR, that the EDG frontend
basically computed a hash from its present compiler state to get a name
for anonymous namespaces? Also, why do these functions get external
linkage at all?

W.

-------------------------------------------------------------------------
Wolfgang Bangerth email: ***@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
Mark Mitchell
2003-04-10 22:33:03 UTC
Permalink
> > This one can't be fixed in the 3.3 time frame, I don't think.
>
> Too bad. Do I get from your explanation in the PR, that the EDG frontend
> basically computed a hash from its present compiler state to get a name
> for anonymous namespaces? Also, why do these functions get external
> linkage at all?

Yes, you can think of it as a hash of its present state.

These functions get external linkage because the C++ standard says they
do. On the other hand, I've never been able to figure out whether a
conforming program could actually *tell*. Adding "export" into the mix
makes it more complicated; now an export template defined in that file
but instantiated somewhere else can see the members of the anonymous
namespace.

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Joe Buck
2003-04-10 22:41:25 UTC
Permalink
On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> These functions get external linkage because the C++ standard says they
> do. On the other hand, I've never been able to figure out whether a
> conforming program could actually *tell*. Adding "export" into the mix
> makes it more complicated; now an export template defined in that file
> but instantiated somewhere else can see the members of the anonymous
> namespace.

Exactly! In the majority of cases there is no conforming program that
can tell the difference between file-static and anonymous namespace.
It appears that exported templates can tell, and there may be a couple
of other similar cases.

My suggestion is to avoid emitting globals for anonymous namespace members
until the end of the unit, at which point any that must be generated are
generated. Names are flagged as "must be generated" when a situation
like a use in an exported template occurs. There may be others, but
I expect them to be rare.
Mark Mitchell
2003-04-10 22:45:23 UTC
Permalink
On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> > These functions get external linkage because the C++ standard says they
> > do. On the other hand, I've never been able to figure out whether a
> > conforming program could actually *tell*. Adding "export" into the mix
> > makes it more complicated; now an export template defined in that file
> > but instantiated somewhere else can see the members of the anonymous
> > namespace.
>
> Exactly! In the majority of cases there is no conforming program that
> can tell the difference between file-static and anonymous namespace.
> It appears that exported templates can tell, and there may be a couple
> of other similar cases.
>
> My suggestion is to avoid emitting globals for anonymous namespace members
> until the end of the unit, at which point any that must be generated are
> generated. Names are flagged as "must be generated" when a situation
> like a use in an exported template occurs. There may be others, but
> I expect them to be rare.

This is all a good idea, and I agree, but I don't think it's appropriate
for 3.3. It's not a trivial change, and the C++ front end is fragile
with respect to emission order, due to the interplay between the varasm
routines and the front end. You can also mess up things like
initialized constants and template instantiation if you're not careful.

Jan's worked on this for 3.4, and doing what you suggest there would
likely make sense.

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Joe Buck
2003-04-10 23:34:59 UTC
Permalink
On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> > My suggestion is to avoid emitting globals for anonymous namespace members
> > until the end of the unit, at which point any that must be generated are
> > generated. Names are flagged as "must be generated" when a situation
> > like a use in an exported template occurs. There may be others, but
> > I expect them to be rare.

On Thu, Apr 10, 2003 at 03:45:23PM -0700, Mark Mitchell wrote:
> This is all a good idea, and I agree, but I don't think it's appropriate
> for 3.3.

It would be OK with me to postpone it to 3.4.
Jan Hubicka
2003-04-10 23:41:49 UTC
Permalink
> On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> > On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> > > These functions get external linkage because the C++ standard says they
> > > do. On the other hand, I've never been able to figure out whether a
> > > conforming program could actually *tell*. Adding "export" into the mix
> > > makes it more complicated; now an export template defined in that file
> > > but instantiated somewhere else can see the members of the anonymous
> > > namespace.
> >
> > Exactly! In the majority of cases there is no conforming program that
> > can tell the difference between file-static and anonymous namespace.
> > It appears that exported templates can tell, and there may be a couple
> > of other similar cases.
> >
> > My suggestion is to avoid emitting globals for anonymous namespace members
> > until the end of the unit, at which point any that must be generated are
> > generated. Names are flagged as "must be generated" when a situation
> > like a use in an exported template occurs. There may be others, but
> > I expect them to be rare.
>
> This is all a good idea, and I agree, but I don't think it's appropriate
> for 3.3. It's not a trivial change, and the C++ front end is fragile
> with respect to emission order, due to the interplay between the varasm
> routines and the front end. You can also mess up things like
> initialized constants and template instantiation if you're not careful.
>
> Jan's worked on this for 3.4, and doing what you suggest there would
> likely make sense.

What do you mean? The unit-at-a-time bits?
I pushed these that I can get across majority of C++ testsuite, however
still some constructors and such appears to be missed in the resulting
binaries. I will try to look into this over weekend and send a
questions if I fail to track this down.

Honza
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> ***@codesourcery.com
>
Mark Mitchell
2003-04-11 00:30:46 UTC
Permalink
On Thu, 2003-04-10 at 16:41, Jan Hubicka wrote:
> > On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> > > On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> > > > These functions get external linkage because the C++ standard says they
> > > > do. On the other hand, I've never been able to figure out whether a
> > > > conforming program could actually *tell*. Adding "export" into the mix
> > > > makes it more complicated; now an export template defined in that file
> > > > but instantiated somewhere else can see the members of the anonymous
> > > > namespace.
> > >
> > > Exactly! In the majority of cases there is no conforming program that
> > > can tell the difference between file-static and anonymous namespace.
> > > It appears that exported templates can tell, and there may be a couple
> > > of other similar cases.
> > >
> > > My suggestion is to avoid emitting globals for anonymous namespace members
> > > until the end of the unit, at which point any that must be generated are
> > > generated. Names are flagged as "must be generated" when a situation
> > > like a use in an exported template occurs. There may be others, but
> > > I expect them to be rare.
> >
> > This is all a good idea, and I agree, but I don't think it's appropriate
> > for 3.3. It's not a trivial change, and the C++ front end is fragile
> > with respect to emission order, due to the interplay between the varasm
> > routines and the front end. You can also mess up things like
> > initialized constants and template instantiation if you're not careful.
> >
> > Jan's worked on this for 3.4, and doing what you suggest there would
> > likely make sense.
>
> What do you mean? The unit-at-a-time bits?

Right. That's what Joe's talking about, but by a different name. If we
had unit-at-a-time, doing the fix that Joe wants would be easy(ish).

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Daniel Jacobowitz
2003-04-10 22:22:32 UTC
Permalink
On Thu, Apr 10, 2003 at 03:16:18PM -0700, Mark Mitchell wrote:
> On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
> >
> > Can I lobby a little for c++/9393? I only rediscovered this these days, so
> > I doubt anyone has looked at it with an angle on 3.3 (because it didn't
> > have priority "high" until very recently). It's
> > - a problem that one cannot work around
> > - generates code that cannot be linked
> > - violates the C++ standard
> > - a regression against 2.95
> > - breaks my application and prevents Brad from running it on his system :-)
>
> We've already fought about this one. :-) See my "Release-Note" there.
>
> This one can't be fixed in the 3.3 time frame, I don't think.

In the interim, couldn't we do something based on a hash of the command
line options, or so? It's not perfect, but it is an improvement; and
there are no binary compatibility issues in choosing the mangled names
for anonymous namespaces, so an interim solution should be acceptable.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Joe Buck
2003-04-10 22:29:46 UTC
Permalink
On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
> >
> > Can I lobby a little for c++/9393? I only rediscovered this these days, so
> > I doubt anyone has looked at it with an angle on 3.3 (because it didn't
> > have priority "high" until very recently). It's
> > - a problem that one cannot work around
> > - generates code that cannot be linked
> > - violates the C++ standard
> > - a regression against 2.95
> > - breaks my application and prevents Brad from running it on his system :-)

On Thu, Apr 10, 2003 at 03:16:18PM -0700, Mark Mitchell wrote:
> We've already fought about this one. :-) See my "Release-Note" there.
>
> This one can't be fixed in the 3.3 time frame, I don't think.

There is a relatively simple, though controversial, "fix": treat
anonymous namespace names as static. There are some problems with
that solution, for example, the question of what happens if there's
a template defined on a type declared in the anonymous namespace, as
well as a few other oddities like that, but the committee intended
anonymous namespaces to replace "static", so in the majority of cases
it should be possible to handle it in the same way.

Even in cases where we don't have a link failure as in 9393, we are
degrading link performance for users that listen to the committee and
replace file-static by anonymous namespace usage.

Possibly some compromise based on filtering could be acceptable: if
there's no reason why an anonymous namespace symbol must be exported,
don't export it, but do export it in cases where this is needed. This
would not completely eliminate the issue, but it would reduce the damage.
That is, only generate anonymous namespace symbols as global in cases
where they are used in a way that requires global-ness.
Branko Čibej
2003-04-10 22:43:49 UTC
Permalink
Joe Buck wrote:

>There is a relatively simple, though controversial, "fix": treat
>anonymous namespace names as static. There are some problems with
>that solution, for example, the question of what happens if there's
>a template defined on a type declared in the anonymous namespace, as
>well as a few other oddities like that, but the committee intended
>anonymous namespaces to replace "static", so in the majority of cases
>it should be possible to handle it in the same way.
>

If I understand correctly, symbols that are defined in an anonymous
namespace can't be used from outside the compilation unit, regardless of
their linkage. If that's correct, then generating a UUID every time a
file is compiled, and using that for the namespace name (suitably
protected with leading underscores), would solve the problems, wouldn't
it? It doesn't matter if a later compile of the same file with the same
compiler options used a different namespace name, because things like
teimpate instantiations based on the anonymous-namespace types would be
regenerated anyway.



--
Brane Čibej <***@xbc.nu> http://www.xbc.nu/brane/
Mark Mitchell
2003-04-10 22:46:51 UTC
Permalink
On Thu, 2003-04-10 at 15:43, Branko Čibej wrote:
> Joe Buck wrote:
>
> >There is a relatively simple, though controversial, "fix": treat
> >anonymous namespace names as static. There are some problems with
> >that solution, for example, the question of what happens if there's
> >a template defined on a type declared in the anonymous namespace, as
> >well as a few other oddities like that, but the committee intended
> >anonymous namespaces to replace "static", so in the majority of cases
> >it should be possible to handle it in the same way.
> >
>
> If I understand correctly, symbols that are defined in an anonymous
> namespace can't be used from outside the compilation unit, regardless of
> their linkage. If that's correct, then generating a UUID every time a
> file is compiled, and using that for the namespace name (suitably
> protected with leading underscores), would solve the problems, wouldn't
> it? It doesn't matter if a later compile of the same file with the same
> compiler options used a different namespace name, because things like
> teimpate instantiations based on the anonymous-namespace types would be
> regenerated anyway.

We've been here before. :-)

We used to randomize the names, which works nicely.

But some programs can use the anonymous namespace members from a place
that is very much like "outside the compilation unit".

Furthermore, non-deterministic compilation was considered a misfeature.

--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Branko Čibej
2003-04-10 22:58:19 UTC
Permalink
Mark Mitchell wrote:

>On Thu, 2003-04-10 at 15:43, Branko Čibej wrote:
>
>
>>If I understand correctly, symbols that are defined in an anonymous
>>namespace can't be used from outside the compilation unit, regardless of
>>their linkage. If that's correct, then generating a UUID every time a
>>file is compiled, and using that for the namespace name (suitably
>>protected with leading underscores), would solve the problems, wouldn't
>>it? It doesn't matter if a later compile of the same file with the same
>>compiler options used a different namespace name, because things like
>>teimpate instantiations based on the anonymous-namespace types would be
>>regenerated anyway.
>>
>>
>
>We've been here before. :-)
>

Ah. I might have known. :-)

>We used to randomize the names, which works nicely.
>
>But some programs can use the anonymous namespace members from a place
>that is very much like "outside the compilation unit".
>

They can? Hmm.
/me tries to think of examples

>Furthermore, non-deterministic compilation was considered a misfeature.
>
>

--
Brane Čibej <***@xbc.nu> http://www.xbc.nu/brane/
Geoff Keating
2003-04-10 23:10:44 UTC
Permalink
Wolfgang Bangerth <***@ices.utexas.edu> writes:

> Can I lobby a little for c++/9393? I only rediscovered this these days, so
> I doubt anyone has looked at it with an angle on 3.3 (because it didn't
> have priority "high" until very recently). It's
> - a problem that one cannot work around
> - generates code that cannot be linked
> - violates the C++ standard
> - a regression against 2.95
> - breaks my application and prevents Brad from running it on his system :-)
>
> (In short: members of anonymous namespaces only get mangled names that
> depend on the file name, nothing else. If you compile the same file twice
> with different flags, then link them together, you'll get linker errors
> about duplicate symbols for all members of anonymous namespaces in this
> file.)

This appears to be an intentional change, but with no justification or
discussion (other than "this fixes my bootstrap"), see

<http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00496.html>

It's clearly wrong because of exactly this case. If people want
reproducible builds, we should have a flag which suppresses the
randomness. I'll work on a quick patch.

--
- Geoffrey Keating <***@geoffk.org>
Nathanael Nerode
2003-04-10 22:24:21 UTC
Permalink
>> (Some of these might be more critical than I'm guessing.)
>> 9738 (mingw/cygwin)
>> 9929 (mingw/cygwin)
>> 10148 (mingw/cygwin)
>> 7910 (mingw/cygwin)
>> 8378 (mingw/cygwin)

>Except for 9929 (which is not mingw/cygwin) all those reports seems to
>involve __attribute__((dllimport))

Yaargh, how did that get on that list? My error.
David Edelsohn
2003-06-06 14:48:36 UTC
Permalink
>>>>> Daniel Jacobowitz writes:

Daniel> On Fri, Jun 06, 2003 at 10:11:10AM -0400, David Edelsohn wrote:
>> I'm seeing gcc.c-torture subdirectories re-run as well. This
>> started happening after I upgraded DejaGNU from the version in the GCC
>> infrastructure directory to the version in CVS to add support for the new
>> assembly tests added by Zack and Zdenek. Only subdirectories more than
>> two levels below the main driver seem to be rerun, e.g., execute/builtins,
>> execute/ieee, cpp/trad.
>>
>> Thanks, David

Daniel> I may be misremembering but I believe HJ Lu posted a DejaGNU patch for
Daniel> this problem - someone was misusing the TCL find command.

Any hint about where the patch is posted and if the patch is
correct/safe?

Thanks, David
H. J. Lu
2003-06-06 14:56:27 UTC
Permalink
On Fri, Jun 06, 2003 at 10:48:36AM -0400, David Edelsohn wrote:
> >>>>> Daniel Jacobowitz writes:
>
> Daniel> On Fri, Jun 06, 2003 at 10:11:10AM -0400, David Edelsohn wrote:
> >> I'm seeing gcc.c-torture subdirectories re-run as well. This
> >> started happening after I upgraded DejaGNU from the version in the GCC
> >> infrastructure directory to the version in CVS to add support for the new
> >> assembly tests added by Zack and Zdenek. Only subdirectories more than
> >> two levels below the main driver seem to be rerun, e.g., execute/builtins,
> >> execute/ieee, cpp/trad.
> >>
> >> Thanks, David
>
> Daniel> I may be misremembering but I believe HJ Lu posted a DejaGNU patch for
> Daniel> this problem - someone was misusing the TCL find command.
>
> Any hint about where the patch is posted and if the patch is
> correct/safe?
>

http://gcc.gnu.org/ml/gcc/2003-05/msg01734.html

If you ask me, this patch is 100% correct/safe.

Since I am on it, I will also recommend

http://mail.gnu.org/archive/html/dejagnu/2003-05/msg00003.html
http://mail.gnu.org/archive/html/dejagnu/2003-05/msg00004.html


H.J.
David Edelsohn
2003-06-17 01:41:28 UTC
Permalink
>>>>> Nathanael Nerode writes:

Nathanael> i370: No maintainer has come forward yet. Currently appears not to
Nathanael> work.

This is being investigated.

David
David Edelsohn
2003-06-17 17:59:27 UTC
Permalink
>>>>> Daniel Jacobowitz writes:

Daniel> Does this mean that we need to move __eprintf from LIB2FUNCS_ST to
Daniel> LIB2FUNCS_2, or that -shared-libgcc should also pull in libgcc.a?

Specifying -shared-libgcc and linking with libgcc.a will cause
problems on some platforms.

David
Daniel Jacobowitz
2003-06-17 17:55:10 UTC
Permalink
I need some second opinions here. The problem:

- My installed GCC is 2.95.3. It has an <assert.h> which references
__eprintf.

- __eprintf is in LIB2FUNCS_ST. So it is not exported shared from
libgcc_s.so.1, and it is marked .hidden in libgcc.a.

- stl-inst.o, when compiled, has two calls to assert which reference
__eprintf. But it's linked with -shared-libgcc, so they are unresolved.

- When linking abi_check, we have a shared library trying to reference a
.hidden symbol in the application. Binutils 2.13 erroneously allowed
this; binutils 2.14 does not.

Does this mean that we need to move __eprintf from LIB2FUNCS_ST to
LIB2FUNCS_2, or that -shared-libgcc should also pull in libgcc.a?

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Continue reading on narkive:
Loading...