Re: Target deprecation, round three

Re: Target deprecation, round three

[Nathanael Nerode]

>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

Re: Target deprecation, round three

[David Edelsohn]

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

Re: Target deprecation, round three

[Nathanael Nerode]

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
> 

Re: Target deprecation, round three

[Nick Ing-Simmons]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
>On 24-Feb-2003, Zack Weinberg <zack@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/

Re: Target deprecation, round three

[Richard Henderson]

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~

Re: Target deprecation, round three

[Richard Henderson]

On Sun, Feb 23, 2003 at 09:47:43PM -0800, Zack Weinberg wrote:
> 	alpha*-*-linux*libc1*

Add alpha*-*-linux*ecoff* to the list to kill.


r~

Re: Target deprecation, round three

[Zack Weinberg]

Joel Sherrill <joel.sherrill@OARcorp.com> writes:

>>    sh-*-rtems* # COFF only
>
> No.  Please keep all sh*-*-rtems* targets.  My comment was that the
> SH is the only CPU which I think should still have an alternate object
> format (sh-rtems == COFF, sh-rtemself == ELF).

Right.  I misunderstood you.  I'll leave this one.

zw

Re: Target deprecation, round three

[Joel Sherrill]

Zack Weinberg wrote:
> 
> So let me get this straight, you are proposing the removal of
> 
>    mips64orion-*-rtems*

Yes.  Deprecate it.

>    sh-*-rtems* # COFF only

No.  Please keep all sh*-*-rtems* targets.  My comment was that the
SH is the only CPU which I think should still have an alternate object
format (sh-rtems == COFF, sh-rtemself == ELF).

>    v850-*-rtems*

Yes.  Deprecate it.

> in addition to what's already on my list (which includes i960-*-rtems*)?
> 
> Does it make sense to keep mips64orion*-*-elf* if RTEMS is gone?

That I don't know.  My impression is that in 3.4 if not now, mips-elf 
includes enough multilibs to properly support mips64 embedded targets.
But the MIPS crew should speak definitively.

> zw

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Target deprecation, round three

[Joel Sherrill]

Zack Weinberg wrote:
> 
> So let me get this straight, you are proposing the removal of
> 
>    mips64orion-*-rtems*

Yes.  Deprecate it.

>    sh-*-rtems* # COFF only

No.  Please keep all sh*-*-rtems* targets.  My comment was that the
SH is the only CPU which I think should still have an alternate object
format (sh-rtems == COFF, sh-rtemself == ELF).

>    v850-*-rtems*

Yes.  Deprecate it.

> in addition to what's already on my list (which includes i960-*-rtems*)?
> 
> Does it make sense to keep mips64orion*-*-elf* if RTEMS is gone?

That I don't know.  My impression is that in 3.4 if not now, mips-elf 
includes enough multilibs to properly support mips64 embedded targets.
But the MIPS crew should speak definitively.

> zw

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Target deprecation, round three

[Zack Weinberg]

So let me get this straight, you are proposing the removal of

   mips64orion-*-rtems*
   sh-*-rtems* # COFF only
   v850-*-rtems*

in addition to what's already on my list (which includes i960-*-rtems*)?

Does it make sense to keep mips64orion*-*-elf* if RTEMS is gone?

zw

Re: Target deprecation, round three

[Chris Lattner]

Fergus Henderson wrote:
>On 24-Feb-2003, Zack Weinberg <zack at codesourcery dot 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 == '/')

Or better yet, how about:

if (c == CHAR_LITERAL('/')) ...

Where on an ascii machine, the CHAR_LITERAL (or whatever) #define just
returns its argument.  On an EBCDIC machine it could index into a 256
element char array to do the mapping.  A bit slower on EBCDIC machines,
but no impact on ASCII machines.

If new code forgets to use the CHAR_LITERAL macro, it would just break on
EBCDIC machines, without affecting the correctness of the ASCII machines.
IMHO, this is better than using a slew of #defines for each character, and
having to remember what each char maps to...

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Re: Target deprecation, round three

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Die, 2003-02-25 um 15.42 schrieb Joel Sherrill:
> > Ralf Corsepius wrote:
> > >
> > > Am Mon, 2003-02-24 um 06.47 schrieb Zack Weinberg:
> > > > Let's try to get a final list for deprecations in the 3.3 release by
> > > > the end of the week.
> > >
> > > IMO, the i?86-go32-rtems target can be removed, too and some of the
> > > *-rtemscoff target are worth being considered to be removed
> > > (There are traces of them in config.gcc)
> > >
> > > At least *-go32-rtems is dead for several years and many (But not all!)
> > > of the *-rtemscoff targets are not actively supported in RTEMS anymore,
> > > either - Joel?
> >
> > Those were deprecated in 3.2.x and now look to produce an error when
> > configured in the 3.3 branch.  They are dead.  AFAIK the only RTEMS
> > target with an later object format is the SH.
> 
> Well, the i960-rtems (coff) still is in (I thought the i960 cou was
> depredicated entirely)

I think 3.3 is the release it will be deprecated in.  It was discussed
a while back and 3.3 was picked at that time as the deprecation point.
RTEMS 4.6 still has i960 support.  We have to make a decision as a
project
how long it should be kept around.  The lack of tools leads me to
clobber it.
 
> The long gone mips64orion-rtems also is still in.

It is still a valid target in RTEMS 4.6 although that will be the last 
release with it.  It can be deprecated in gcc 3.3.  The requirement was
that mips-rtems can build and link all mips1 and mips3 BSPs and with 
gcc 3.3, that works.  So gcc 3.2.2 will be that last gcc RTEMS RPMS 
are available for this target.

> And then there is a target called v850-rtems which I have heard about
> (I.e. it probably is not supported by RTEMS since < ~1997)

Abandoned port that was started by someone and never finished.  I always
wanted to see it finished but it never got returned to by anyone.  It 
can be deprecated it now.

> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Target deprecation, round three

[Ralf Corsepius]

Am Die, 2003-02-25 um 15.42 schrieb Joel Sherrill:
> Ralf Corsepius wrote:
> > 
> > Am Mon, 2003-02-24 um 06.47 schrieb Zack Weinberg:
> > > Let's try to get a final list for deprecations in the 3.3 release by
> > > the end of the week.
> > 
> > IMO, the i?86-go32-rtems target can be removed, too and some of the
> > *-rtemscoff target are worth being considered to be removed
> > (There are traces of them in config.gcc)
> > 
> > At least *-go32-rtems is dead for several years and many (But not all!)
> > of the *-rtemscoff targets are not actively supported in RTEMS anymore,
> > either - Joel?
> 
> Those were deprecated in 3.2.x and now look to produce an error when
> configured in the 3.3 branch.  They are dead.  AFAIK the only RTEMS
> target with an later object format is the SH.  

Well, the i960-rtems (coff) still is in (I thought the i960 cou was
depredicated entirely)

The long gone mips64orion-rtems also is still in.

And then there is a target called v850-rtems which I have heard about
(I.e. it probably is not supported by RTEMS since < ~1997)

Ralf

Re: Target deprecation, round three

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Mon, 2003-02-24 um 06.47 schrieb Zack Weinberg:
> > Let's try to get a final list for deprecations in the 3.3 release by
> > the end of the week.
> 
> IMO, the i?86-go32-rtems target can be removed, too and some of the
> *-rtemscoff target are worth being considered to be removed
> (There are traces of them in config.gcc)
> 
> At least *-go32-rtems is dead for several years and many (But not all!)
> of the *-rtemscoff targets are not actively supported in RTEMS anymore,
> either - Joel?

Those were deprecated in 3.2.x and now look to produce an error when
configured in the 3.3 branch.  They are dead.  AFAIK the only RTEMS
target with an later object format is the SH.  

> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Target deprecation, round three

[Ralf Corsepius]

Am Mon, 2003-02-24 um 06.47 schrieb Zack Weinberg:
> Let's try to get a final list for deprecations in the 3.3 release by
> the end of the week.

IMO, the i?86-go32-rtems target can be removed, too and some of the
*-rtemscoff target are worth being considered to be removed
(There are traces of them in config.gcc)

At least *-go32-rtems is dead for several years and many (But not all!)
of the *-rtemscoff targets are not actively supported in RTEMS anymore,
either - Joel?

Ralf

Re: Target deprecation, round three

[Tolga Dalman]

On Mon, 24 Feb 2003 19:51:17 -0500 David Edelsohn <dje@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.

Re: Target deprecation, round three

[Fergus Henderson]

On 24-Feb-2003, Zack Weinberg <zack@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 <fjh@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.

Re: Target deprecation, round three

[David Edelsohn]

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

David

Re: Target deprecation, round three

[Steven Bosscher]

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

Re: Target deprecation, round three

[Zack Weinberg]

Mark Mitchell <mark@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

Re: Target deprecation, round three

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

David

Re: Target deprecation, round three

[David Edelsohn]

>>>>> Mark Mitchell writes:

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

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

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

	The s390 port assumes S/390 architecture, ASCII, ELF file format,
flat addressing model, lower case mnemonics, Linux runtime.

	The i370 port supports S/370 architecture, EBCDIC, GOFF file
format, base/displacement addressing, upper case mnemonics, MVS/LE or
Dignus runtime environment.

	The two could be merged together, but the s390 port was not
designed with that in mind and the i370 port was designed before Linux on
S/390 was developed.  They are designed for very different environments.

	I have been exchanging email with Dave Pitts and he wants to
maintain the i370 port if we would encourage rather than discourage it
with other changes that have created problems for EBCDIC support.

Thanks, David

Re: Target deprecation, round three

[Daniel Jacobowitz]

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

Re: Target deprecation, round three

[Mark Mitchell]

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
mark@codesourcery.com

Re: Target deprecation, round three

[Andreas Schwab]

Zack Weinberg <zack@codesourcery.com> writes:

|> 	m68k-*-linux*aout*
|> 	m68k-*-linux*libc1

Let them rest in peace.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Target deprecation, round three

[Nick Burrett]

Zack Weinberg wrote:

> The majority of the targets on my "round two" list
> (http://gcc.gnu.org/ml/gcc/2002-12/msg00702.html) went over without
> comment.  With a couple of exceptions I've dropped the targets which
> someone spoke up in favor of; let's discuss the exceptions a bit more
> carefully.  (If your favorite target is still on the list, speak up!
> If you did already, it means I lost your mail; my apologies, and
> please remind me.)
> 
> I'm pushing back on the following:

> 	arm*-*-aof*
> 
>   This target is responsible for masses of #ifdefs all over the ARM
>   back end.  Is it *really* necessary to continue using this rather
>   quirky assembler?  Could you perhaps move to GAS and arm-elf
>   instead?

Unfortunately this is not possible, though I've considered switching to 
GAS and arm-elf in the past.  RISC OS does not support ELF binaries.

However the rest of the code and patches to support RISC OS are kept in 
my own private tree, so it is feasible for me to just move the AOF stuff 
into my own set of patches.

It would be handy if you could leave it in for 3.3, then dump it for 3.4 
and later releases if you like.

Cheers,


Nick.

Re: Target deprecation, round three

[Franz Sirl]

On Monday 24 February 2003 06:47, Zack Weinberg wrote:
> 	powerpc*-*-linux*libc1*

This one is certainly OK to remove.

Franz.

Re: Target deprecation, round three

[David Edelsohn]

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

Re: Target deprecation, round three

[Zack Weinberg]

David Edelsohn <dje@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

Re: Target deprecation, round three

[Gabriel Dos Reis]

David Edelsohn <dje@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

Re: Target deprecation, round three

[David Edelsohn]

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

Re: Target deprecation, round three

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Zack Weinberg <zack@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

Re: Target deprecation, round three

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Zack Weinberg <zack@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

Re: Target deprecation, round three

[Gabriel Dos Reis]

Zack Weinberg <zack@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

Re: Target deprecation, round three

[Zack Weinberg]

DJ Delorie <dj@redhat.com> writes:

>> 	i?86-*-coff*
>
> Note that both DJGPP and Cygwin are x86-coff derivatives.  We don't
> use the "i?86-*-coff*" triplet, but most of the COFF support will need
> to remain anyway.

In that case it probably makes sense to keep the generic COFF target.

zw

Re: Target deprecation, round three

[DJ Delorie]

> 	i?86-*-coff*

Note that both DJGPP and Cygwin are x86-coff derivatives.  We don't
use the "i?86-*-coff*" triplet, but most of the COFF support will need
to remain anyway.

Re: Target deprecation, round three

[Zack Weinberg]

David Edelsohn <dje@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

Re: Target deprecation, round three

[David Edelsohn]

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

Re: Target deprecation, round three

[Hans-Peter Nilsson]

> From: Zack Weinberg <zack@codesourcery.com>
> Date: Mon, 24 Feb 2003 09:45:58 -0800

> So I take it that your interest is exclusively in i?86-*-linux*libc1*,
> you have no use for the other libc1 ports?

Correct.

brgds, H-P

Re: Target deprecation, round three

[Zack Weinberg]

Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

> It seems you misread.  There was no paragraph "right under" the
> line I quoted; as quoted above ;-) I quoted from the list below
> the line "Current list of targets to deprecate:".  The
> discussion in a paragraph *above* that list ("right under" a
> similar triplet-line) indicated you meant to keep it
> (i.e. remove it from the deprecation list), but it was still
> there, which indicated you still wanted to deprecate it.  Or
> something.  Oh well, I guess we're in violent agreement. ;-)

Sorry for the confusion.  I left all of the targets called out for
discussion in the big list.  The discussion was intended to supersede
mention in the big list.

So I take it that your interest is exclusively in i?86-*-linux*libc1*,
you have no use for the other libc1 ports?

zw

Re: Target deprecation, round three

[Hans-Peter Nilsson]

> From: Zack Weinberg <zack@codesourcery.com>
> Date: Mon, 24 Feb 2003 09:18:26 -0800

> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> >> From: Zack Weinberg <zack@codesourcery.com>
> >> Date: Sun, 23 Feb 2003 21:47:43 -0800
> >
> >> Current list of targets to deprecate:
> >
> >> 	i?86-*-linux*libc1
> >
> > Please don't.  I have no issues with restricting it to C only
> > though.
> 
> Er, did you read the paragraph right under this?

It seems you misread.  There was no paragraph "right under" the
line I quoted; as quoted above ;-) I quoted from the list below
the line "Current list of targets to deprecate:".  The
discussion in a paragraph *above* that list ("right under" a
similar triplet-line) indicated you meant to keep it
(i.e. remove it from the deprecation list), but it was still
there, which indicated you still wanted to deprecate it.  Or
something.  Oh well, I guess we're in violent agreement. ;-)

brgds, H-P

Re: Target deprecation, round three

[Zack Weinberg]

Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

>> From: Zack Weinberg <zack@codesourcery.com>
>> Date: Sun, 23 Feb 2003 21:47:43 -0800
>
>> Current list of targets to deprecate:
>
>> 	i?86-*-linux*libc1
>
> Please don't.  I have no issues with restricting it to C only
> though.

Er, did you read the paragraph right under this?  The current question
with the *-*-linux*libc1 targets is *which ones* to keep - it's clear
that there is interest in i386, but what about the others?

zw

Re: Target deprecation, round three

[Zack Weinberg]

David Edelsohn <dje@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

Re: Target deprecation, round three

[David Edelsohn]

>>>>> Andreas Jaeger writes:

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

	Yes, it has been working for many GCC releases.  Initially as a
cross-compiler and later as a native compiler in the Open Edition / Unix
System Services environment.

David

Re: Target deprecation, round three

[Andreas Jaeger]

David Edelsohn <dje@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 aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Target deprecation, round three

[David Edelsohn]

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

Re: Target deprecation, round three

[Daniel Jacobowitz]

On Sun, Feb 23, 2003 at 09:47:43PM -0800, Zack Weinberg wrote:
> In addition to target deprecation, I would also like to propose the
> removal of support for DWARF version 1.  There are only two target
> patterns that request DWARF 1 but not DWARF 2: mips-sni-sysv4, which
> is already on the deprecation list, and arc-*-*, which I see no
> intrinsic reason why it couldn't migrate to DWARF 2; it is already an
> ELF target.  Tangentially, my impression is that the ARC target itself
> is still actively maintained, but I am not sure.  Please speak up if
> you have a current need for this target.

[This is not a request to keep it.  I beg you not to count it as one.]

There are a number of hardware + closed source software debugger
combinations - I know of one for ARM and one for PowerPC - that only
speak DWARF 1.  I've seen people using these within the past month. 
So, as broken as our DWARF1 output is (very) and as sad as it makes me,
I don't think we can ditch it yet.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Target deprecation, round three

[Hans-Peter Nilsson]

> From: Zack Weinberg <zack@codesourcery.com>
> Date: Sun, 23 Feb 2003 21:47:43 -0800

> Current list of targets to deprecate:

> 	i?86-*-linux*libc1

Please don't.  I have no issues with restricting it to C only
though.

brgds, H-P

Target deprecation, round three

[Zack Weinberg]

Let's try to get a final list for deprecations in the 3.3 release by
the end of the week.  I once again have to apologize for dropping the
ball.

The majority of the targets on my "round two" list
(http://gcc.gnu.org/ml/gcc/2002-12/msg00702.html) went over without
comment.  With a couple of exceptions I've dropped the targets which
someone spoke up in favor of; let's discuss the exceptions a bit more
carefully.  (If your favorite target is still on the list, speak up!
If you did already, it means I lost your mail; my apologies, and
please remind me.)

I'm pushing back on the following:

	i370-*-*

  All respect to the people who continue working on this back end, but
  they are doing so outside the official repository and have shown no
  interest in merging their work back.  Also, this is the same
  architecture as the s390-*-* back end, which is actively maintained.
  It would be better for the health of the compiler as a whole if that
  back end were augmented to support the things that it currently
  doesn't but the i370 back end does.

  Note that this is the only back end which defines HOST_EBCDIC and
  TARGET_EBCDIC.  There is no difficulty in continuing to support
  TARGET_EBCDIC - the s390 back end might plausibly want to use it in
  the future - but supporting HOST_EBCDIC in conjunction with certain
  features of C99 (which effectively require internal use of the ISO
  10646 aka Unicode charset) would force us to make substantial
  changes to the C front end that would leave it much harder to
  maintain.  (The short version is that character constants could not
  be used anywhere.)  Thus I would like to drop HOST_EBCDIC
  permanently at the same time this target is removed.  This does
  *not* mean the compiler will be unable to accept input files encoded
  in EBCDIC; it only means that it will itself need to be built in an
  environment where the execution character set is a superset of ASCII.

	alpha*-*-linux*libc1*
	i?86-*-linux*libc1*
	m68k-*-linux*libc1*
	powerpc*-*-linux*libc1*
	sparc-*-linux*libc1*

  I received a couple of messages expressing continued interest in
  some of these targets.  I have no problem keeping those that are
  actually used; however, I am not clear on which those are.  Is it
  just ix86, or are others in use too, and if so which ones?

	arm*-*-aof*

  This target is responsible for masses of #ifdefs all over the ARM
  back end.  Is it *really* necessary to continue using this rather
  quirky assembler?  Could you perhaps move to GAS and arm-elf
  instead?

        m68k-sun-sunos*
        sparc-sun-sunos*

  These targets are hosted systems with C libraries that predate C89,
  which means they impose disproportionate maintenance burdens.  They
  have long since been EOLed by Sun.  Please advise whether you really
  need a 3.x GCC for these targets.

In addition to target deprecation, I would also like to propose the
removal of support for DWARF version 1.  There are only two target
patterns that request DWARF 1 but not DWARF 2: mips-sni-sysv4, which
is already on the deprecation list, and arc-*-*, which I see no
intrinsic reason why it couldn't migrate to DWARF 2; it is already an
ELF target.  Tangentially, my impression is that the ARC target itself
is still actively maintained, but I am not sure.  Please speak up if
you have a current need for this target.

zw

Current list of targets to deprecate:

        i370-*-*
        i960-*-*
        m88k-*-*
        romp-*-*

	alpha*-*-interix*
	alpha*-*-linux*libc1*

	arm*-*-aout*
	arm*-*-aof*
	arm*-*-conix*
	arm*-*-oabi
	strongarm-*-coff*

	hppa1.0-*-osf*
	hppa1.0-*-bsd*
	hppa1.[01]-*-hpux[789]*
	hppa*-*-hiux*
	hppa*-*-lites*
	hppa*-*-mpeix*

	i?86-ncr-*
	i?86-sequent-*
	i?86-moss-*
	i?86-*-netware
	i?86-*-freebsd2*
	i?86-*-netbsd*aout*
	i?86-*-coff*
	i?86-*-linux*aout*
	i?86-*-linux*libc1
	i?86-*-moss*
	i?86-*-sysv3*
	i?86-*-vsta
	i?86-*-interix # not interix3

	m68000-hp-bsd*
	m68000-hp-hpux*
	m68000-sun-sunos*
	m68000-att-sysv*
	m68k-atari-sysv*
	m68k-motorola-sysv*
	m68k-ncr-sysv*
	m68k-plexus-sysv*
	m68k-tti-*
	m68k-crds-unos*
	m68k-cbm-sysv*
	m68k-ccur-rtu*
	m68k-hp-bsd*
	m68k-hp-hpux*
	m68k-sun-mach*
	m68k-sun-sunos*
	m68k-*-linux*aout*
	m68k-*-linux*libc1
	m68k-*-psos*

	mips*-*-ecoff*
        mips-sni-sysv4

	powerpc*-*-sysv*  # the generic one only
	powerpc*-*-linux*libc1
	rs6000-ibm-aix[123]*
	rs6000-bull-bosx
	rs6000-*-mach*

	sparc-*-aout*
	sparc-*-netbsd*aout*
	sparc-*-bsd*
	sparc-*-chorusos*
	sparc-*-linux*aout*
	sparc-*-linux*libc1*
	sparc-*-lynxos*
	sparc-hal-solaris2*
	sparc-*-sunos[34]*
	sparclet-*-aout*
	sparclite-*-coff*
	sparclite-*-aout*
	sparc86x-*-aout*

	vax-*-bsd*
	vax-*-sysv*
	vax-*-netbsd*aout*
        vax-*-vms*