Re: Removal of V2 code

Re: Removal of V2 code

[Kaveh R. Ghazi]

 > From: Mark Mitchell <mark@codesourcery.com>
 > 
 >     Geoff> Does SunOS (not Solaris) work?  I think we still have SunOS
 >     Geoff> customers.
 > 
 > I don't know about SunOS either.  Kaveh?

I mentioned this to Mark offline, but it deserves wider attention.
the SunOS box I had access to died and its sysadmin decided not to
revive it.  Therefore I cannot assist in testing or V3 porting to
SunOS.

I've felt SunOS a worthy second tier candidate for these reasons:

Tests K&R stage1 support
Tests fixincludes thoroughly
Tests SJLJ exceptions
Tests other various missing OS feature handling in gcc

I hope someone will volunteer to champion SunOS in lieu of me.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

sun/os as release candidate was: Removal of V2 code

[Robert Lipe]

Kaveh R. Ghazi wrote:

> the SunOS box I had access to died

While I'm sorry for your loss, there are ways to help coverage even in
the absence of such a system.

> I've felt SunOS a worthy second tier candidate for these reasons:
> 
> Tests K&R stage1 support

Many modern compilers have flags to dumb them down to K&R mode.  Perhaps
this could be accomplished by doing bootstraps with a compiler in such a
mode.  I suspect that "gcc -ansi" is probably not the best test, but it
might suffice.  Some vendor compiler might be a better test.

Someone that cares about K&R could step up to the plate to add a cron
job to do a nightly (or whatever) build on such a system.

Does anyone other than HP even still provide a K&R-only compiler?  If
so, since there are binary kits of GCC available for that target, has
the time come for us to relax the K&R restriction for bootstrapping GCC
completely?

> Tests SJLJ exceptions

OpenServer in COFF mode uses SJLJ exceptions.  (It's one reason I'm
strongly considering yanking COFF mode; sjlj and dwarf-1 problems
are apparently of decreasing strategic value to GCC and they break
frequently.)  This could be exercised somewhat by one of the nightly
build processes by adding another pass with '-fsjlj-exceptions' or even
doing a bootstrap by adding it to BOOT_CLFAGS.  This could give us
coverage on a system that doesn't _need_ SJLJ.

> Tests fixincludes thoroughly
> Tests other various missing OS feature handling in gcc

Those represent holes.  OTOH, maybe they represent holes that are of
only of value on such an archaic target...I mean, does any actively
maintained host/target still really spell "memcpy" only as "bcopy"?

RJL

Re: Removal of V2 code

[law]

  In message < 200011201655.LAA09289@caip.rutgers.edu >you write:
  > I mentioned this to Mark offline, but it deserves wider attention.
  > the SunOS box I had access to died and its sysadmin decided not to
  > revive it.  Therefore I cannot assist in testing or V3 porting to
  > SunOS.
  > 
  > I've felt SunOS a worthy second tier candidate for these reasons:
  > 
  > Tests K&R stage1 support
  > Tests fixincludes thoroughly
  > Tests SJLJ exceptions
FWIW, if we can get the PA/hpux bits in libstdc++-v3 up and running, then
the PA port can test those issues pretty well :-)

jeff

Re: sun/os as release candidate was: Removal of V2 code

[Gerald Pfeifer]

On Mon, 20 Nov 2000, Robert Lipe wrote:
> Someone that cares about K&R could step up to the plate to add a cron
> job to do a nightly (or whatever) build on such a system.

Exactly. And if there's none left who cares about K&R, well, than at some
point in the future we should decide that this requirement will go away.

> Does anyone other than HP even still provide a K&R-only compiler?  If
> so, since there are binary kits of GCC available for that target, has
> the time come for us to relax the K&R restriction for bootstrapping GCC
> completely?

Personally, I wouldn't mind very much... (But we shouldn't do this
lightly and really check that no platforms in use break.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: sun/os as release candidate was: Removal of V2 code

[Zack Weinberg]

On Mon, Nov 20, 2000 at 03:51:34PM -0500, Kaveh R. Ghazi wrote:
>  > From: Robert Lipe <robertlipe@usa.net>
>  > 
>  > Kaveh R. Ghazi wrote:
>  > 
>  > > I've felt SunOS a worthy second tier candidate for these reasons:
>  > > 
>  > > Tests K&R stage1 support
>  > 
>  > Many modern compilers have flags to dumb them down to K&R mode.  Perhaps
>  > this could be accomplished by doing bootstraps with a compiler in such a
>  > mode.  I suspect that "gcc -ansi" is probably not the best test, but it
>  > might suffice.  Some vendor compiler might be a better test.
> 
> I think you meant "gcc -traditional".
> 
> The problem with this kind of testing is that when you tell an ANSI
> compiler to "dumb down" to traditional C, many still accept (some)
> ANSI constructs.  E.g. Irix6's "cc -cckr" or "gcc -traditional" still
> accept prototypes.  I'm sure other obscure things will come up.  I
> think I recall hpux's cc did a good job being really traditional.

You also run into problems with system headers that use ANSI
constructs.  For instance, GNU libc's headers haven't been K+R clean
since the 2.0 release, and in 2.2 they gave up even pretending to
support pre-ANSI.  The headers have bare prototypes, unqualified
"const", use ## unconditionally to paste tokens, etc.  This means gcc
-traditional is unusable on more or less all Linux systems.

If I were in charge of testing K+R compatibility, I'd get a Vax
emulator, install 4.3BSD on it, and set up a build environment inside
there.  That's overkill; 4.3 doesn't even have #elif.  But that means
if GCC works on it, it *will* run on everything that people actually
use in real life.

zw

Re: sun/os as release candidate was: Removal of V2 code

[Kaveh R. Ghazi]

 > From: Robert Lipe <robertlipe@usa.net>
 > 
 > Kaveh R. Ghazi wrote:
 > 
 > > I've felt SunOS a worthy second tier candidate for these reasons:
 > > 
 > > Tests K&R stage1 support
 > 
 > Many modern compilers have flags to dumb them down to K&R mode.  Perhaps
 > this could be accomplished by doing bootstraps with a compiler in such a
 > mode.  I suspect that "gcc -ansi" is probably not the best test, but it
 > might suffice.  Some vendor compiler might be a better test.

I think you meant "gcc -traditional".

The problem with this kind of testing is that when you tell an ANSI
compiler to "dumb down" to traditional C, many still accept (some)
ANSI constructs.  E.g. Irix6's "cc -cckr" or "gcc -traditional" still
accept prototypes.  I'm sure other obscure things will come up.  I
think I recall hpux's cc did a good job being really traditional.

Anyway, I agree it's certainly better than nothing.  I'm trying to get
current CVS stage1 bootstrapable with "gcc -traditional".  There are
some problems with the switchover to tradcpp0 which I'll try to
address.  But faking K&R with "gcc -traditional" is not really a
substitute for bootstrapping with a real K&R compiler in a true K&R
environment (libc & headers) IMHO.


 > > Tests other various missing OS feature handling in gcc
 > 
 > Those represent holes.  OTOH, maybe they represent holes that are of
 > only of value on such an archaic target...I mean, does any actively
 > maintained host/target still really spell "memcpy" only as "bcopy"?
 > RJL

That's a really simple case.  Think about more intesting stuff like
long double or long long support, %p, broken mmap, broken ctypes,
intmax_t, enumerated bitfields, missing iconv, missing wide char
support, complex multilibs, missing atexit, AC_CHECK_DECLS, missing
threads, missing -c/-o, etc etc.

I know many (most) of these are missing/broken in some combination on
other platforms, but SunOS4 pretty much tops the list of problematic
platforms unless you go back to svr3. :-)

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions