testing consistency

testing consistency

[Joe Buck]

I think that I'd like to see a bit more discipline in how we do testing.
Many of us are doing various tests now, but I do want to make sure that
we cover the cases that users are likely to use.

This means that we should make sure to test the compilers that are built
by following the (yet to be written) instructions exactly, that is,
bootstrap the compiler and build with "-O2 -g", then doing tests with
"clean" environments (nothing else installed: e.g. no libg++ if it isn't
part of egcs).  Additional tests with higher optimization levels and
extra headers are welcome but should be considered "extra".

Ideally, it should be extremely simple to run a "standard test" and
do a full report of results, and mail it back to a standard address.
e.g.

./configure
make
make test_and_report

The idea is that this runs all the test suites, collects all of the
relevant data, and sends it in a mail message.  It would be nice if
cruft is deleted so the mail message isn't full of garbage.

Relevant data that we wouldn't want to miss includes:
	configure options (including platform)
	libc version, if relevant
	assembler and linker versions, if relevant
	gcc options used to compile the final gcc (e.g. -O2 -g)

It may be hard to collect that automatically -- maybe we can just have
a standard "test report template".  It could even be a WWW form.

This process shouldn't be too bureaucratic, but I'd like to be able to
say with confidence that "the following list of platforms passes all
tests" (OK, maybe there is a small set of known failures).

Re: testing consistency

[Dave Avery]

Joe Buck wrote:
 
> This means that we should make sure to test the compilers that are built
> by following the (yet to be written) instructions exactly, that is,
> bootstrap the compiler and build with "-O2 -g", then doing tests with
> "clean" environments (nothing else installed: e.g. no libg++ if it isn't
> part of egcs).  Additional tests with higher optimization levels and
> extra headers are welcome but should be considered "extra".

also we should check -Ox without -g .  I know in the past this
combination was explicitly noted as possibly dangerous

dave

Re: testing consistency

[Jim Wilson]

	also we should check -Ox without -g .  I know in the past this
	combination was explicitly noted as possibly dangerous

It is a gcc policy that -Ox -g should always generate exactly the same code
as -Ox.  So there should not be anything dangerous with using just -Ox,
other than the fact that you won't be able to debug the code if it ever
fails.  Of course, it doesn't hurt to test it every once in a while to make
sure this is still true.

Jim

Re: testing consistency

[Joe Buck]

> It is a gcc policy that -Ox -g should always generate exactly the same code
> as -Ox.

I know (but do we have any tests that assure this?).  However, in the past
I've seen compilers (g++, plus some vendor compilers) that blow their
cookies when writing out debug information for files that are successfully
compiled.  Thus I think we have to make sure that gcc bootstraps correctly
with -g enabled.

Re: testing consistency

[Joe Buck]

> also we should check -Ox without -g .  I know in the past this
> combination was explicitly noted as possibly dangerous

By whom?  -Ox with -g, as Jim Wilson writes, generates exactly the same
code as -Ox without -g.  The worst that can happen is that debugging
can be confusing.

Re: testing consistency

[Joel Sherrill]

On Thu, 4 Sep 1997, Joe Buck wrote:

> This means that we should make sure to test the compilers that are built
> by following the (yet to be written) instructions exactly, that is,
> bootstrap the compiler and build with "-O2 -g", then doing tests with
> "clean" environments (nothing else installed: e.g. no libg++ if it isn't
> part of egcs).  Additional tests with higher optimization levels and
> extra headers are welcome but should be considered "extra".

I know I have built this way out of habit for years. :)

> Ideally, it should be extremely simple to run a "standard test" and
> do a full report of results, and mail it back to a standard address.
> e.g.
> 
> ./configure
> make
> make test_and_report
> 
> The idea is that this runs all the test suites, collects all of the
> relevant data, and sends it in a mail message.  It would be nice if
> cruft is deleted so the mail message isn't full of garbage.

This would also need to include a "compile but don't execute and report" 
for cross environments.  It would certainly save me a lot of setup effort.
:)

--joel

Re: testing consistency

[Jeffrey A Law]

  In message < Pine.BSF.3.96.970905083457.28375A-100000@vespucci.advicom.net >you write:
  > > The idea is that this runs all the test suites, collects all of the
  > > relevant data, and sends it in a mail message.  It would be nice if
  > > cruft is deleted so the mail message isn't full of garbage.
  > 
  > This would also need to include a "compile but don't execute and report" 
  > for cross environments.  It would certainly save me a lot of setup effort. :)
This should work if you've got an assembler, linker and libraries available.

The testsuite will build the executable, then fail trying to run it.

Jeff

Re: testing consistency

[Joel Sherrill]

On Fri, 5 Sep 1997, Jeffrey A Law wrote:

>   > This would also need to include a "compile but don't execute and report" 
>   > for cross environments.  It would certainly save me a lot of setup effort. :)
> This should work if you've got an assembler, linker and libraries available.

This will always be the case for rtems configurations since I use binutils
and do a one-tree build every time.

> The testsuite will build the executable, then fail trying to run it.

I guess that is OK as long as it is clear which are compile time failures
and which are blowing up on running it.

--joel

Re: testing consistency

[Jeffrey A Law]

  In message < 199709050148.SAA15882@atrus.synopsys.com >you write:
  > I think that I'd like to see a bit more discipline in how we do testing.
  > Many of us are doing various tests now, but I do want to make sure that
  > we cover the cases that users are likely to use.
I'll second this.  It's going to be extremely difficult to get a good
quality release out if everyone isn't bootstrapping and testing in
a similar manner.  Bootstrapping with additional flags and testing with
additional flags are useful, but we've got to get the base stuff solid
first.

This is critical to getting a release solidified and out the door.

The first step in this process is to get everyone to bootstrap in the
same manner.  Is anyone else using the rough toplevel "bootstrap"
target I posted last week?  Comments and improvements are definitely
welcome!

  > Ideally, it should be extremely simple to run a "standard test" and
  > do a full report of results, and mail it back to a standard address.
  > e.g.
  > 
  > ./configure
  > make
  > make test_and_report
Don't forgot "make install" at the end -- it's been a source of problems
and we need to make sure it works.

Jeff

Re: testing consistency

[Joe Buck]

I wrote:
>   > I think that I'd like to see a bit more discipline in how we do testing.
>   > Many of us are doing various tests now, but I do want to make sure that
>   > we cover the cases that users are likely to use.

Jeff writes:

> The first step in this process is to get everyone to bootstrap in the
> same manner.  Is anyone else using the rough toplevel "bootstrap"
> target I posted last week?  Comments and improvements are definitely
> welcome!

I haven't yet tried it, I have a script that configures, cd's to gcc
and does the standard 3-stage bootstrap and install, then cd's back and
does make and make install.  I'll try it out.

In the meantime, the biggest remaining lack of consistency is caused by
the g++ tests that depend on libg++ classes that are not in libstdc++.
These fail for those who haven't installed libg++ in a place where egcs
will find it and pass for others.  They need to be rewritten or dropped.

This affects seven files:

g++.brendan/crash20.C (includes Complex.h)
g++.brendan/crash30.C (String.h)
g++.brendan/crash39.C (GetOpt.h, String.h)
g++.law/operators4.C (Complex.h)
g++.mike/p658.C (bool.h)
g++.mike/p784.C (bool.h)
g++.mike/p785.C (bool.h)

I suggest the following fixes:
* For the first four tests, replace them with the preprocessor output
  using libg++, or else move them to the libg++ test suite.
* For the last three, eliminate bool.h (it has no effect on compilation
  for these tests, after the preprocessor the token stream is the same).

A trivial patch (in the directory gcc/testsuite/g++.old-deja/g++.mike --
this patch avoids changing any line numbers)

ChangeLog:
	* g++.old-deja/g++.mike/p658.C: eliminate <bool.h> use.
	* g++.old-deja/g++.mike/p784.C: Ditto.
	* g++.old-deja/g++.mike/p785.C: Ditto.

	p658.C
*** p658.C	Tue Aug 19 00:34:51 1997
--- p658-fix.C	Wed Sep 10 15:49:13 1997
***************
*** 1,7 ****
  // prms-id: 658
  
  #include <ostream.h>
! #include <bool.h>
  extern "C" void abort();
  
  /* We may not find the libg++ <bool.h>.  */
--- 1,7 ----
  // prms-id: 658
  
  #include <ostream.h>
! 
  extern "C" void abort();
  
  /* We may not find the libg++ <bool.h>.  */
*** p784.C	Tue Aug 19 00:34:52 1997
--- p784-fix.C	Wed Sep 10 15:49:44 1997
***************
*** 134,140 ****
  // $Revision: 1.1.1.1 $
  // $Date: 1997/08/19 07:34:52 $
  
! #include <bool.h>
  
  //# 25 "../../GctSymbol.h" 2
  
--- 134,140 ----
  // $Revision: 1.1.1.1 $
  // $Date: 1997/08/19 07:34:52 $
  
! 
  
  //# 25 "../../GctSymbol.h" 2
  
*** p785.C	Tue Aug 19 00:34:52 1997
--- p785-fix.C	Wed Sep 10 15:51:19 1997
***************
*** 3246,3252 ****
  // $Revision: 1.1.1.1 $
  // $Date: 1997/08/19 07:34:52 $
  
! #include <bool.h>
  
  //# 25 "../../../../mips/include/Gct/Reference/GctReferenceCount.h" 2
  
--- 3246,3252 ----
  // $Revision: 1.1.1.1 $
  // $Date: 1997/08/19 07:34:52 $
  
! 
  
  //# 25 "../../../../mips/include/Gct/Reference/GctReferenceCount.h" 2
  

Re: testing consistency

[Jeffrey A Law]

  In message < 199709102302.QAA21704@atrus.synopsys.com >you write:
  > I haven't yet tried it, I have a script that configures, cd's to gcc
  > and does the standard 3-stage bootstrap and install, then cd's back and
  > does make and make install.  I'll try it out.
I've got a better one just about ready (it'll die if the bootstrap or
comparison stages fail.  It also tells users in human terms what it's
doing :-)

I'm planning on a snapshot later tonight, and I'll include the prototype
"make bootstrap" toplevel target.

[ It won't work for cross builds, which is something we'll have to deal with. ]


  > In the meantime, the biggest remaining lack of consistency is caused by
  > the g++ tests that depend on libg++ classes that are not in libstdc++.
  > These fail for those who haven't installed libg++ in a place where egcs
  > will find it and pass for others.  They need to be rewritten or dropped.
Yup.    I'll look over this stuff shortly, hopefully I'll include your
changes in tonight's snapshot.

Jeff

Re: testing consistency

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Joe Buck writes:

> * For the first four tests, replace them with the preprocessor output
>   using libg++, or else move them to the libg++ test suite.

Here are patches for these four tests.  The crash* ones may be
affected by the changes, but since the current snapshot passes them,
and it has passed them for a long time, I don't think they are that
relevant any more.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

[-- Attachment #2: g++tsts.diff --]
[-- Type: text/x-diff, Size: 2040 bytes --]

--- gcc/testsuite/g++.old-deja/g++.brendan/crash20.C~	Mon Aug 25 12:34:53 1997
+++ gcc/testsuite/g++.old-deja/g++.brendan/crash20.C	Thu Sep 11 02:06:17 1997
@@ -1,6 +1,7 @@
 // Build don't link: 
 // GROUPS passed old-abort
-#include <Complex.h>
+#include <complex>
+typedef complex<double> Complex;
 
 Complex ComputeVVself()
 {
--- gcc/testsuite/g++.old-deja/g++.brendan/crash30.C~	Mon Aug 25 12:34:53 1997
+++ gcc/testsuite/g++.old-deja/g++.brendan/crash30.C	Thu Sep 11 02:06:51 1997
@@ -1,9 +1,9 @@
 // Build don't link: 
 // GROUPS passed old-abort
-#include <String.h>
+#include <string>
 
 main(void) {
 
-  String a[] = {"Hello"};
+  string a[] = {"Hello"};
 
 }
--- gcc/testsuite/g++.old-deja/g++.brendan/crash39.C~	Thu Sep 11 02:14:06 1997
+++ gcc/testsuite/g++.old-deja/g++.brendan/crash39.C	Thu Sep 11 02:13:31 1997
@@ -1,8 +1,34 @@
 // Build don't link: 
 // Special g++ Options: -w
 // GROUPS passed old-abort
-#include <GetOpt.h>
-#include <String.h>
+//#include <GetOpt.h>
+#include <std.h>
+#include <stdio.h>
+
+class GetOpt
+{
+private:
+  static char *nextchar;
+   enum OrderingEnum { REQUIRE_ORDER, PERMUTE, RETURN_IN_ORDER };
+   OrderingEnum ordering;
+  static int first_nonopt;
+  static int last_nonopt;
+  void exchange (char **argv);
+public:
+  char *optarg;
+  int optind;
+  int opterr;
+  
+  int    nargc;
+  char **nargv;
+  const char  *noptstring;
+  
+  GetOpt (int argc, char **argv, const char *optstring);
+  int operator () (void);
+};
+//end <GetOpt.h>
+#include <string>
+
 class foo {public: foo () {}};
 class bar {public: bar (foo& dflt);};
 class baz: public bar {public: baz (): bar (foo ()) {}};
--- gcc/testsuite/g++.old-deja/g++.law/operators4.C~	Mon Aug 25 12:36:02 1997
+++ gcc/testsuite/g++.old-deja/g++.law/operators4.C	Thu Sep 11 02:06:12 1997
@@ -5,7 +5,8 @@
 // Subject:  delete [size] pointer; Problem
 // Message-ID: <92Sep3.220137edt.30@jarvis.csri.toronto.edu>
 
-#include <Complex.h>
+#include <complex>
+typedef complex<double> Complex;
 #include <stdio.h>
 
 class Vector {

Re: testing consistency

[Jeffrey A Law]

  In message < or3enc1l80.fsf@sunsite.dcc.unicamp.br >you write:
  > Here are patches for these four tests.  The crash* ones may be
  > affected by the changes, but since the current snapshot passes them,
  > and it has passed them for a long time, I don't think they are that
  > relevant any more.
Agreed.  I've installed the changes.

Thanks!
jeff

Re: testing consistency

[Jeffrey A Law]

  In message < 199709102302.QAA21704@atrus.synopsys.com >you write:
  > I haven't yet tried it, I have a script that configures, cd's to gcc
  > and does the standard 3-stage bootstrap and install, then cd's back and
  > does make and make install.  I'll try it out.
OK.  The 970910 has my updated bootstrap target.  Should be noticably
better than the old one.  Still doesn't work for cross targets though.

  > I suggest the following fixes:
  > * For the first four tests, replace them with the preprocessor output
  >   using libg++, or else move them to the libg++ test suite.
  > * For the last three, eliminate bool.h (it has no effect on compilation
  >   for these tests, after the preprocessor the token stream is the same).
  > 
  > A trivial patch (in the directory gcc/testsuite/g++.old-deja/g++.mike --
  > this patch avoids changing any line numbers)
Your changes didn't make it into 970910, but they will be in the next
snapshot (I just installed them).  I'll be looking at Alexandre Oliva's
changes in a couple minutes.

(Basically I ended up burning time trying to deal with problems exposed
by a new stl import, which I just ended up avoiding for this snapshot).

Jeff

Re: testing consistency

[meissner]

| On Fri, 5 Sep 1997, Jeffrey A Law wrote:
| 
| >   > This would also need to include a "compile but don't execute and report" 
| >   > for cross environments.  It would certainly save me a lot of setup effort. :)
| > This should work if you've got an assembler, linker and libraries available.
| 
| This will always be the case for rtems configurations since I use binutils
| and do a one-tree build every time.
| 
| > The testsuite will build the executable, then fail trying to run it.
| 
| I guess that is OK as long as it is clear which are compile time failures
| and which are blowing up on running it.

You could always configure it so that it uses a simulator of /bin/true to run
the program.

Re: testing consistency

[Joel Sherrill]

On Fri, 5 Sep 1997 meissner@cygnus.com wrote:

> You could always configure it so that it uses a simulator of /bin/true to run
> the program.

Great idea!!! I wish I had thought of it. :)

--joel

Re: testing consistency

[Aaron Jackson]

I have tried to use the bootstrap target you posted several times, both
on the 970904 and the 970907 snapshot and was NEVER able to get past the
first stage build.  I finally gave up on egcs and just compiled and
installed gcc2.7.2.2 and g770.5.20.  I tried on both ultrix 4.4 and
digital unix 2.0 systems.  I would like to stay current with all these
many patches and improvements posted so far, and I'll give it another try
with the next snapshot, although I loath the four hour compile times and
I get really bummed when it doesn't work.

Aaron Jackson		jackson@msrce.howard.edu

>The first step in this process is to get everyone to bootstrap in the
>same manner.  Is anyone else using the rough toplevel "bootstrap"
>target I posted last week?  Comments and improvements are definitely
>welcome!

Re: testing consistency

[Jim Wilson]

If you run into bugs, please report them.  We only fix bugs that we know
about.

I see that you did report a problem once earlier, but that was due to the
fact that you tried to build the Fortran front end in the first stage build.
This does not work unless you are compiling with gcc.  This problem goes
away if you use the normal gcc bootstrap build process before building the
rest of EGCS.  This will happen automatically with the new bootstrap target.

If there are other problems, then please report them.

Jim

Re: testing consistency

[Jeffrey A Law]

  In message < 9709110529.AA03191@negril.msrce.howard.edu >you write:
  > I have tried to use the bootstrap target you posted several times, both
  > on the 970904 and the 970907 snapshot and was NEVER able to get past the
  > first stage build.
Did you report bugs?  I only remember one bug report from you, and that
was not using the "bootstrap" target.

In fact, the bug you reported was one of the prime reasons why we need
a bootstrap target -- fortran won't build without gcc.

If you don't report bugs, then we can't fix them.

jeff

Re: testing consistency

[H.J. Lu]

> 
> I have tried to use the bootstrap target you posted several times, both
> on the 970904 and the 970907 snapshot and was NEVER able to get past the
> first stage build.  I finally gave up on egcs and just compiled and
> installed gcc2.7.2.2 and g770.5.20.  I tried on both ultrix 4.4 and
> digital unix 2.0 systems.  I would like to stay current with all these
> many patches and improvements posted so far, and I'll give it another try
> with the next snapshot, although I loath the four hour compile times and
> I get really bummed when it doesn't work.
> 

Ok. That is what I have been doing:

# cd bin/gcc-debug
# ../../../egcs/gcc/configure 
# make bootstrap
# make install
# cd ../egcs
# ../../../egcs/configure
# make
# make check
# make install

BTW, egcs/configure is broken for linux or any native
platforms. I have sent in this patch to fix it for linux:

Mon Aug 25 17:31:49 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* configure (prefix): Initialized to NONE. Set to
	${native_prefix} for Linux or ${default_prefix} for others if
	it is NONE.
	(default_prefix): New. Initialized to /usr/local.
	(native_prefix): New. Initialized to /usr.

to fix it. But I got no positive reponse.


H.J.
----
Index: configure
===================================================================
RCS file: /home/work/cvs/gnu/egcs/configure,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure
--- configure	1997/08/26 00:20:39	1.1.1.1
+++ configure	1997/08/27 03:10:10
@@ -62,7 +62,9 @@
 norecursion=
 other_options=
 package_makefile_frag=
-prefix=/usr/local
+prefix=NONE
+default_prefix=/usr/local
+native_prefix=/usr
 progname=
 program_prefix=
 program_prefixoption=
@@ -512,6 +514,18 @@
         fi
 esac
 
+# Are we using gcc as the native compiler?
+if [ x${prefix} = xNONE ]; then
+	case ${host_alias} in
+	*linux*)	# All Linux's use gcc as the native compiler.
+		prefix=${native_prefix}
+		;;
+	*)
+		prefix=${default_prefix}
+		;;
+	esac
+fi
+
 # default exec_prefix
 case "${exec_prefixoption}" in
 "") exec_prefix="\$(prefix)" ;;

Re: testing consistency

[Jeffrey A Law]

  In message < m0x9CrQ-0004ecC@ocean.lucon.org >you write:
  > BTW, egcs/configure is broken for linux or any native
  > platforms. I have sent in this patch to fix it for linux:
Please explain _why_ it is broken.  You never did this, and
thus I've put that patch near the bottom of my queue.

The toplevel configure is essentially what Cygnus has been using
for years to build a huge variety of native, cross and canadian
cross toolchains.  You can't just say it's broken and expect us
to change it without explaining what's wrong with it.

Maybe it's broken for linux, if so you should say that, and explain
_why_ it is broken for linux and why your patch is the correct
solution (both for linux and for other platforms)

I've still got a copy of the patch, and someday it'll be at the top
of my queue and I'll try to answer those questions myself.  But that
might be a long time away.


Jim may have different opinions about that patch, but I've got no
intention of installing it until someone answers those questions.

jeff

Re: testing consistency

[H.J. Lu]

> 
> 
>   In message < m0x9CrQ-0004ecC@ocean.lucon.org >you write:
>   > BTW, egcs/configure is broken for linux or any native
>   > platforms. I have sent in this patch to fix it for linux:
> Please explain _why_ it is broken.  You never did this, and
> thus I've put that patch near the bottom of my queue.
> 
> The toplevel configure is essentially what Cygnus has been using
> for years to build a huge variety of native, cross and canadian
> cross toolchains.  You can't just say it's broken and expect us
> to change it without explaining what's wrong with it.
> 
> Maybe it's broken for linux, if so you should say that, and explain
> _why_ it is broken for linux and why your patch is the correct
> solution (both for linux and for other platforms)
> 

When you do

# configure

on linux or any platforms where gcc is the native, default
compiler, prefix should be /usr, not /usr/local. Please
check out egcs/gcc/configure.in to see what it does.


H.J.

Re: testing consistency

[Jeffrey A Law]

  In message < m0x9DaB-0004ecC@ocean.lucon.org >you write:
  > When you do
  > 
  > # configure
  > 
  > on linux or any platforms where gcc is the native, default
  > compiler, prefix should be /usr, not /usr/local. Please
  > check out egcs/gcc/configure.in to see what it does.
I disagree.

I've worked on such systems for years; and if installing egcs
overwrote my system compiler I'd scream bloody murder.

Overwriting the default native compiler should require explicit
"permission" from the user -- ie "--prefix=/usr".

jeff

Re: testing consistency

[H.J. Lu]

> 
> 
>   In message < m0x9DaB-0004ecC@ocean.lucon.org >you write:
>   > When you do
>   > 
>   > # configure
>   > 
>   > on linux or any platforms where gcc is the native, default
>   > compiler, prefix should be /usr, not /usr/local. Please
>   > check out egcs/gcc/configure.in to see what it does.
> I disagree.
> 
> I've worked on such systems for years; and if installing egcs
> overwrote my system compiler I'd scream bloody murder.

I only said "using gcc as the default compiler".

> 
> Overwriting the default native compiler should require explicit
> "permission" from the user -- ie "--prefix=/usr".
> 

That is kind of strange.

1. Only the gcc driver is overridden. The compiler is still
there.
2. Install egcs usually means an update. Say my OS has no
compiler, I got a gcc binary and I installed it under /usr/local.
Does egcs do anything to avoid "overwriting" my "default"
compiler?

Install gcc under /usr on linux has been done for years now.
Why a sudden change? For linux users, it will only cause
more confusions since the egcs binary release will be installed
in /usr, not /usr/local. The same goes for glibc, which has
wider impact than gcc. glibc is installed under /usr on linux
unless being told otherwise.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: testing consistency

[Jeffrey A Law]

  In message < m0x9Dxj-0004ecC@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m0x9DaB-0004ecC@ocean.lucon.org >you write:
  > >   > When you do
  > >   > 
  > >   > # configure
  > >   > 
  > >   > on linux or any platforms where gcc is the native, default
  > >   > compiler, prefix should be /usr, not /usr/local. Please
  > >   > check out egcs/gcc/configure.in to see what it does.
  > > I disagree.
  > > 
  > > I've worked on such systems for years; and if installing egcs
  > > overwrote my system compiler I'd scream bloody murder.
  > 
  > I only said "using gcc as the default compiler".
default compiler == system compiler or am I missing something?

  > > Overwriting the default native compiler should require explicit
  > > "permission" from the user -- ie "--prefix=/usr".
  > > 
  > 
  > That is kind of strange.
  > 
  > 1. Only the gcc driver is overridden. The compiler is still
  > there.
Right, but instead of getting the compiler which you know works and
won't scrog your kernel, init or something else important you're
getting a new compiler which you likely know little about.

If you want to install egcs as the default compiler for you system,
you'll have to use a prefix option.

Yes, the old compiler is still there, but by default you'll end up
with the new, less tested egcs compiler.  And when you go to build
your kernel and it doesn't work you're going to be pissed.

  > Install gcc under /usr on linux has been done for years now.
I assume because of various hacks you've been distributing to the
linux community, or has there been something in the standard gcc
releases to do this?

gcc has always installed itself into /usr/local by default and
that's the behavior the vast majority of users expect.

Having gcc install itself into /usr seems absolutely and horribly
wrong to me.  I won't install that patch.

Jim, of course, may have different opinions.

jeff

Re: testing consistency

[H.J. Lu]

>   > Install gcc under /usr on linux has been done for years now.
> I assume because of various hacks you've been distributing to the
> linux community, or has there been something in the standard gcc
> releases to do this?
> 

Yes, gcc 2.7.2.3 and the next gcc 2.8. If you do

# ../egcs/gcc/configure
# make bootstrap
# make install

on linux, gcc will be installed in /usr. BTW, I
always have a back copy of my default gcc driver.
It is a good idea regardless where gcc is installed.


H.J.

Re: testing consistency

[Jeffrey A Law]

  In message < m0x9ElJ-0004ecC@ocean.lucon.org >you write:
  > >   > Install gcc under /usr on linux has been done for years now.
  > > I assume because of various hacks you've been distributing to the
  > > linux community, or has there been something in the standard gcc
  > > releases to do this?
  > > 
  > 
  > Yes, gcc 2.7.2.3 and the next gcc 2.8. If you do
"Yes" to which question?  There are two questions in my message
which are mutually exclusive.

I can imply the right answer from the rest of your message, but
being explicit with your answers will save both of us time and
potential confusion.

Based on the rest of your message the answer is "yes, there has
been something in the standard gcc releases to do this".

How long has this been true?  This is more a curiousity on my
part.


  > # ../egcs/gcc/configure
  > # make bootstrap
  > # make install
  > 
  > on linux, gcc will be installed in /usr. BTW, I
  > always have a back copy of my default gcc driver.
  > It is a good idea regardless where gcc is installed.
Well, I still think it's the wrong thing to do, but if Richard
Henderson or someone else familiar with linux sez it's OK, then
I'll go ahead and install the changes.

Jeff

Re: testing consistency

[Per Bothner]

> Based on the rest of your message the answer is "yes, there has
> been something in the standard gcc releases to do this".

There does seem to be.  That is a bug that should be fixed.

> on linux, gcc will be installed in /usr.

99% of Linux users use a distribution, such as Debian or RedHat.
/usr should belong to the distribution.  For user to randomly
add packages to /usr is wrong, because it reduces the effectiveness
of using a package management system.  For example, if /usr/bin/gcc
is overridden, the package system may complain when it is time to
do a laietr update.  And a later package update will fail to remove
the user-installed gcc-lib.

Packages manually compiled by the user (not using the package management
system) belong in /usr/local, not /usr, on any well-run Linux system.

Yes, I have violated this rule.  But gcc should not do it by default.

> Well, I still think it's the wrong thing to do, but if Richard
> Henderson or someone else familiar with linux sez it's OK, then
> I'll go ahead and install the changes.

I say: don't.  It's wrong.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: testing consistency

[Richard Henderson]

> Packages manually compiled by the user (not using the package management
> system) belong in /usr/local, not /usr, on any well-run Linux system.
> 
> Yes, I have violated this rule.  But gcc should not do it by default.

I think I agree with Per on this issue.  The package manager has control
of /usr, and /usr/local is strictly off-limits to the manager.

Besides, it isn't like you have to patch gcc to get it to go either place,
argument(s) to configure is all it takes.


r~

Re: testing consistency

[Bob Glickstein]

Per Bothner writes:
> Packages manually compiled by the user (not using the package
> management system) belong in /usr/local, not /usr, on any well-run
> Linux system.

Furthermore, a tool like GNU Stow helps manage the contents of a tree
like /usr/local.  Please see

  http://www.gnu.ai.mit.edu/software/stow/

Re: testing consistency

[Jim Wilson]

	  > Install gcc under /usr on linux has been done for years now.
	I assume because of various hacks you've been distributing to the
	linux community, or has there been something in the standard gcc
	releases to do this?

No, it has been a standard part of gcc for quite a while.

	gcc has always installed itself into /usr/local by default and
	that's the behavior the vast majority of users expect.

Except under linux, where it installs by default into /usr.

	Having gcc install itself into /usr seems absolutely and horribly
	wrong to me.  I won't install that patch.

Consider what happens if HP sends you a compiler upgrade for your HP machine.
Does it go into /usr/local?  No.  It goes in /usr.  gcc plays the same role
for Linux.  If we release an official upgraded version of gcc for Linux, then
it should go in /usr by default.

There are two considerations here.  Developers playing with gcc snapshots,
and end users trying to upgrade their compiler to the new version.  A
developer would not want to install into /usr, because a snapshot bug might
break your system.  On the other hand, an end user must install into /usr,
otherwise, they haven't actually upgraded the compiler on their system.

Since these are contrary goals, we must choose which one is not the default.
It is generally preferable to make things harder for the developer, since
they are expected to be able to deal with any problems.  Also, we don't want
to tell Linux people that they need to apply patches before they can install
gcc correctly.  Hence, installs into /usr should be the default.

This particular issue incidentally has been debated before among the gcc2
developers.  I don't see any particular need to reopen the issue.

Jim

Re: testing consistency

[Per Bothner]

> Consider what happens if HP sends you a compiler upgrade for your HP machine.
> Does it go into /usr/local?  No.  It goes in /usr.

The correspondong scenario is a Debian/RedHat/Slackware *binary package*.
That is of course installed into /usr.

> On the other hand, an end user must install into /usr, 
> otherwise, they haven't actually upgraded the compiler on their system.

End users should only compile from source as a last resort.
Otherwise, they should get an updated package from Debian/RedHat/Slackware.

> It is generally preferable to make things harder for the developer, since 
> they are expected to be able to deal with any problems. 

Agreed.  And it is more difficult if gcc is installed in /usr,
for any Linux system based on Debian/RedHat/Slackware, unless
it is installed as a package upgrade.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: testing consistency

[Jeffrey A Law]

  In message < 199709112036.NAA08062@cygnus.com >you write:
  > No, it has been a standard part of gcc for quite a while.
I think I'm going to puke...

Good thing it wasn't for any system I regularly work on.

  > 	Having gcc install itself into /usr seems absolutely and horribly
  > 	wrong to me.  I won't install that patch.
  > 
  > Consider what happens if HP sends you a compiler upgrade for your HP machine  > .
  > Does it go into /usr/local?  No.  It goes in /usr.
HP is shipping me a _binary_.

That's very different from someone picking up egcs/gcc source on the
net and _building_ it.  As much as we'd like to think it's a simple
process people manage to goof far too often.

  > There are two considerations here.  Developers playing with gcc snapshots,
  > and end users trying to upgrade their compiler to the new version.  A
  > developer would not want to install into /usr, because a snapshot bug might
  > break your system.  On the other hand, an end user must install into /usr,
  > otherwise, they haven't actually upgraded the compiler on their system.
  > 
  > Since these are contrary goals, we must choose which one is not the default.
  > It is generally preferable to make things harder for the developer, since
  > they are expected to be able to deal with any problems.  Also, we don't want
  > to tell Linux people that they need to apply patches before they can install
  > gcc correctly.  Hence, installs into /usr should be the default.
I agree with most of your general thoughts, particularly who to
make things harder on.

However, I still find the idea of gcc installing itself into
/usr by default repulsive.

  > This particular issue incidentally has been debated before among the gcc2
  > developers.  I don't see any particular need to reopen the issue.
Well, just because gcc2 does something doesn't mean we have to.


Now, having said all that, I'm not going to argue the issue anymore;
Jim if you want, go ahead and install the patch.  I won't object.

I'll do it myself if other linux folks speak up in favor of
the patch to install egcs into /usr by default.

jeff

Re: testing consistency

[Joe Buck]

> However, I still find the idea of gcc installing itself into
> /usr by default repulsive.

Perhaps HJ is responding to my often-expressed desire that when people
build the compiler themselves they get the same one that he distributes
in binary form.

To make myself clear, it's fine that users get the same compiler HJ
distributes if they say --prefix=/usr .

Re: testing consistency

[Jim Wilson]

My initial concern here is that there were mistakes in the arguments.
People were claiming that H.J.'s patch was changing behaviour, when in
fact it was restoring behaviour that was lost when we added the toplevel
directory.  If we choose not to accept H.J.'s patch, then we are deciding
to change how gcc operates.

Now that there has been so much discussion of it, we may as well revisit
whether the old behaviour was correct.

	HP is shipping me a _binary_.
	That's very different from someone picking up egcs/gcc source on the
	net and _building_ it.  

Yes.  I agree that this this a good argument against it.  Also, the arguments
about how installing into /usr will wreak havoc with people who have done
package installs.

Another argument which I am not sure if anyone has made yet is that changing
the toplevel configure will affect more packages than just gcc.  Checking
libio/libstdc++, I see that they don't default to prefix=/usr, so we may
not want to force that to be true.  If we eventually try to share this
tree with other packages, like binutils and gdb, then we are also changing
them if we change the toplevel configure.

I will talk to H.J. Lu about this.

Incidentally, if we don't accept H.J.'s patch, then we need to fix the
gcc/configure.in file to avoid conflicts over the default value of prefix.
There was a bug report posted within the last week of someone who got a
non-functional gcc because they made the mistake of configuring in the gcc
directory (defaulting to prefix=/usr) and then installing from the toplevel
directory (defaulting to prefix=/usr/local), so gcc was installed some place
differently than it expected to be installed.

Jim

Re: testing consistency

[Joe Buck]

> My initial concern here is that there were mistakes in the arguments.
> People were claiming that H.J.'s patch was changing behaviour, when in
> fact it was restoring behaviour that was lost when we added the toplevel
> directory.  If we choose not to accept H.J.'s patch, then we are deciding
> to change how gcc operates.

Even if gcc is "right", perhaps egcs and gcc should not have the same
behavior in this case.  The official compiler going in /usr is one thing,
the experimental egcs compiler going in /usr is quite another.

> Incidentally, if we don't accept H.J.'s patch, then we need to fix the
> gcc/configure.in file to avoid conflicts over the default value of prefix.

Just use /usr/local everywhere.  Conflict gone.  (but I think gcc should
work that way too).

Re: testing consistency

[Per Bothner]

> Install gcc under /usr on linux has been done for years now.
> Why a sudden change? For linux users, it will only cause
> more confusions since the egcs binary release will be installed
> in /usr, not /usr/local. The same goes for glibc, which has
> wider impact than gcc. glibc is installed under /usr on linux
> unless being told otherwise.

Most Linux users should install gcc as part of a package.
When you install gcc or glibc packaged as an .rpm or .deb package
(as part of a Linux distribution), it should of course go in /usr.

When you build gcc from source, it should *by default* install
in /usr/local, *just like all other GNU packages*.

The paths should be different in the two situations.

If you (or a Linux package maintainer) want to make make a binary
release, you should configure it with --prefix=/usr - just like all
other GNU packages.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: testing consistency

[Paul Koning]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

 Jeffrey> In message < m0x9DaB-0004ecC@ocean.lucon.org >you write:
 >> When you do
 >> 
 >> # configure
 >> 
 >> on linux or any platforms where gcc is the native, default
 >> compiler, prefix should be /usr, not /usr/local. Please check out
 >> egcs/gcc/configure.in to see what it does.
 Jeffrey> I disagree.

 Jeffrey> I've worked on such systems for years; and if installing
 Jeffrey> egcs overwrote my system compiler I'd scream bloody murder.

 Jeffrey> Overwriting the default native compiler should require
 Jeffrey> explicit "permission" from the user -- ie "--prefix=/usr".

I strongly agree with Jeff.

Weren't there some complaints a while back about egcs build
overwriting things (like the texi to info tools)?  

The default should be a safe default.  That's especially true for beta
software, but even beyond that.  (Just because beta is finished
doesn't mean the bugs are all gone.)

In production environments, people *don't* just plunk a new tool over
an older one just because it was released...  

	paul

Re: testing consistency

[Ian Lance Taylor]

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 11 Sep 1997 10:16:56 -0700 (PDT)

   BTW, egcs/configure is broken for linux or any native
   platforms. I have sent in this patch to fix it for linux:

   Mon Aug 25 17:31:49 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	   * configure (prefix): Initialized to NONE. Set to
	   ${native_prefix} for Linux or ${default_prefix} for others if
	   it is NONE.
	   (default_prefix): New. Initialized to /usr/local.
	   (native_prefix): New. Initialized to /usr.

   to fix it. But I got no positive reponse.

It would probably be more appropriate to patch this in configure.in
rather than in configure.

Ian

Re: testing consistency

[H.J. Lu]

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Thu, 11 Sep 1997 10:16:56 -0700 (PDT)
> 
>    BTW, egcs/configure is broken for linux or any native
>    platforms. I have sent in this patch to fix it for linux:
> 
>    Mon Aug 25 17:31:49 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)
> 
> 	   * configure (prefix): Initialized to NONE. Set to
> 	   ${native_prefix} for Linux or ${default_prefix} for others if
> 	   it is NONE.
> 	   (default_prefix): New. Initialized to /usr/local.
> 	   (native_prefix): New. Initialized to /usr.
> 
>    to fix it. But I got no positive reponse.
> 
> It would probably be more appropriate to patch this in configure.in
> rather than in configure.
> 

configure.in in egcs has nothing to do with autoconf. Yes,
I did

# autoconf

in egcs a few times when it was late. It took me half an hour
to figure out why configure was zero length.



-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: testing consistency

[Ian Lance Taylor]

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 11 Sep 1997 13:50:51 -0700 (PDT)

   configure.in in egcs has nothing to do with autoconf.

I know.

I still think it would be more appropriate to make this change in
configure.in rather than in configure.  System specific hacks like
this one normally go in the top level configure.in, not in the top
level configure.

Ian

Re: testing consistency

[H.J. Lu]

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Thu, 11 Sep 1997 13:50:51 -0700 (PDT)
> 
>    configure.in in egcs has nothing to do with autoconf.
> 
> I know.
> 
> I still think it would be more appropriate to make this change in
> configure.in rather than in configure.  System specific hacks like
> this one normally go in the top level configure.in, not in the top
> level configure.
> 

Since it is prefix, I don't know how to do it without touching
configure.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: testing consistency

[Ian Lance Taylor]

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 11 Sep 1997 13:57:40 -0700 (PDT)

   > I still think it would be more appropriate to make this change in
   > configure.in rather than in configure.  System specific hacks like
   > this one normally go in the top level configure.in, not in the top
   > level configure.

   Since it is prefix, I don't know how to do it without touching
   configure.

I see the problem.  configure is fine with me.

I agree with others that setting the prefix in this manner is odd
behaviour.

Ian

Re: testing consistency

[Jim Wilson]

OK, everyone has agreed now that requiring people to use --prefix=/usr instead
of defaulting it is OK for linux.

I have checked in the following patch to eliminate places that were already
doing this.

Thu Sep 11 17:43:55 1997  Jim Wilson  <wilson@cygnus.com>

	* configure.in (native_prefix): Delete.
	(mips-dec-netbsd): Don't set prefix.
	(*linux*): Don't set prefix.

Index: configure.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/configure.in,v
retrieving revision 1.18
diff -p -r1.18 configure.in
*** configure.in	1997/09/12 00:39:08	1.18
--- configure.in	1997/09/12 00:45:33
***************
*** 24,30 ****
  AC_INIT(tree.c)
  AC_CONFIG_HEADER(config.h:config.in)
  
- native_prefix=/usr
  remove=rm
  hard_link=ln
  symbolic_link='ln -s'
--- 24,29 ----
*************** for machine in $build $host $target; do
*** 1767,1776 ****
  		# On NetBSD, the headers are already okay.
  		fixincludes=Makefile.in
  		tmake_file=t-netbsd
- 		if [[ x$prefix = xNONE ]]; then
- 			prefix=$native_prefix
- 		fi
- 		prefix=$native_prefix
  		;;
  	mips-sony-bsd* | mips-sony-newsos*)	# Sony NEWS 3600 or risc/news.
  		tm_file=mips/news4.h
--- 1766,1771 ----
*************** fi
*** 2768,2782 ****
  
  # Get the version number from the toplevel
  version=`sed -e 's/.*\"\([[^ \"]]*\)[[ \"]].*/\1/' < ${srcdir}/version.c`
- 
- # Are we using gcc as the native compiler?
- case $host in
- *linux*)	# All Linux's use gcc as the native compiler.
- 	if [[ x$prefix = xNONE ]]; then
- 		prefix=$native_prefix
- 	fi
- 	;;
- esac
  
  # Get an absolute path to the GCC top-level source directory
  holddir=`pwd`
--- 2763,2768 ----

Re: testing consistency

[Joel Sherrill]

> >The first step in this process is to get everyone to bootstrap in the
> >same manner.  Is anyone else using the rough toplevel "bootstrap"
> >target I posted last week?  Comments and improvements are definitely
> >welcome!

What would be the best thing to do for the embedded cross targets?

Re: testing consistency

[Jeffrey A Law]

  In message < Pine.BSF.3.96.970914140454.8969D-100000@vespucci.advicom.net >you write:
  > > >The first step in this process is to get everyone to bootstrap in the
  > > >same manner.  Is anyone else using the rough toplevel "bootstrap"
  > > >target I posted last week?  Comments and improvements are definitely
  > > >welcome!
  > 
  > What would be the best thing to do for the embedded cross targets?
I'm tempted to create a make target which does something like this:

  Build random things that gcc needs for rebuilding files
   (texinfo, bison/yacc and the like).

  Build various target tools (gas, ld, etc)

  Build gcc using LANGUAGES="c c++"

  Build target libs with LANGUAGES="c c++"


This may just mean adding the LANGUAGES= stuff to an existing
target.

This avoids the g77 & objc stuff until we move the objc & g77
runtime into their own toplevel directories.

I'm happy ot do stuff based on your direction/feedback -- that's just
my general idea.

jeff

Re: testing consistency

[Joel Sherrill]

On Sun, 14 Sep 1997, Jeffrey A Law wrote:

> This avoids the g77 & objc stuff until we move the objc & g77
> runtime into their own toplevel directories.
> 
> I'm happy ot do stuff based on your direction/feedback -- that's just
> my general idea.

I think your idea is consisten with what I have been doing.  Building all
the tools from scratch and then just making sure the result can at
least compile and link all the RTEMS tests.  

I wish I knew how to test more of the libraries in the tree.  I do not
know how to do anything with the C++ libraries or newlib.

--joel

Re: testing consistency

[Jeffrey A Law]

  In message < Pine.BSF.3.96.970914144154.8969G-100000@vespucci.advicom.net >you write:
  > I think your idea is consisten with what I have been doing.  Building all
  > the tools from scratch and then just making sure the result can at
  > least compile and link all the RTEMS tests.  
OK.  The next snapshot will contain the "cross" target, which does pretty
much what I mentioned in that message:

  * Build all the stuff necesary to generate files during the build
  process (texinfo, bison/yacc, etc).

  * Build all the target tools that might be needed while building
  gcc (ie gas, ld, etc)

  * Build GCC using LANGUAGES="c c++" to avoid objc & f77.  Hmmm, should
  this include "proto" to build protoize/unprotoize?

  * Build the rest of the target libraries with the newly built compiler.


Give it a whirl when you can and let me know how it goes.
jeff

Re: testing consistency

[H.J. Lu]

> 
>   * Build GCC using LANGUAGES="c c++" to avoid objc & f77.  Hmmm, should
>   this include "proto" to build protoize/unprotoize?
> 

Even when I did this, egcs still configures for "f" and creats those
files in "f" during make.



H.J.

Re: testing consistency

[Jeffrey A Law]

  In message < m0xC4b3-0004ecC@ocean.lucon.org >you write:
  > > 
  > >   * Build GCC using LANGUAGES="c c++" to avoid objc & f77.  Hmmm, should
  > >   this include "proto" to build protoize/unprotoize?
  > > 
  > 
  > Even when I did this, egcs still configures for "f" and creats those
  > files in "f" during make.
Correct, but it doesn't try to build any of the fortran stuff or
objc stuff, which avoids losing for cross builds.

jeff

Re: testing consistency

[Jim Wilson]

	Even when I did this, egcs still configures for "f" and creats those
	files in "f" during make.

This is intentional.  It was necessary to avoid a circular dependence between
the f77 runtime and the C++ libgcc.a code.  This problem will go away when the
f77 runtime is moved to the toplevel directory along side the C++ runtime.

Meanwhile, f77 gets configured, but does not get built, so there is no problem
other than the fact that builds take a little longer than necessary.

Jim

Re: testing consistency

[Joe Buck]

> Meanwhile, f77 gets configured, but does not get built, so there is no
> problem other than the fact that builds take a little longer than
> necessary.

Another problem is that, the way the configure is done, it is easy to wind
up with bad data in the config.cache files for the f77 runtime.  The
reason is that you wind up with something like the following in
gcc/f/runtime/config.cache (I've replaced the directory containing
the egcs distribution with <SRCDIR>).

ac_cv_prog_CC=${ac_cv_prog_CC='<SRCDIR>/gcc/xgcc -B<SRCDIR>/gcc/'}

It's easy to arrive at a situation where configure is re-run in this
directory but the pointed-to xgcc no longer exists; if so, builds fail
even if you say LANGUAGES=c.

It would be more robust if we could avoid placing definitions of
ac_cv_prog_CC like this in the cache.

Re: testing consistency

[Dave Love]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

 Joe> Another problem is that, the way the configure is done, it is
 Joe> easy to wind up with bad data in the config.cache files for the
 Joe> f77 runtime.  The reason is that you wind up with something like
 Joe> the following in gcc/f/runtime/config.cache (I've replaced the
 Joe> directory containing the egcs distribution with <SRCDIR>).

 Joe> ac_cv_prog_CC=${ac_cv_prog_CC='<SRCDIR>/gcc/xgcc -B<SRCDIR>/gcc/'}

The cache file has been taken out of the `clean' target for some
reason.  It was there advisedly, normal GNU standards notwithstanding.
[This is one complication with using automake for the runtime.]

 Joe> It would be more robust if we could avoid placing definitions of
 Joe> ac_cv_prog_CC like this in the cache.

The idea was always to be sure the correct compiler was being used by
configure.  I don't remember the cache file being a particular problem
during g77 development with the released GCCs (especially wrt bug
reports), though I've personally fallen over various things like this
occasionally :-/.

Re: testing consistency

[Jeffrey A Law]

  In message < 199709192013.NAA23049@atrus.synopsys.com >you write:
  > Another problem is that, the way the configure is done, it is easy to wind
  > up with bad data in the config.cache files for the f77 runtime.  The
  > reason is that you wind up with something like the following in
  > gcc/f/runtime/config.cache (I've replaced the directory containing
  > the egcs distribution with <SRCDIR>).
[ ... ]
I think this problem will disappear when we move the runtime stuff in
its own subdir. 

jeff

Re: testing consistency

[Mike Stump]

> To: Aaron Jackson <jackson@negril.msrce.howard.edu>
> cc: egcs@cygnus.com
> Date: Thu, 11 Sep 1997 00:39:56 -0700
> From: Jim Wilson <wilson@cygnus.com>

> I see that you did report a problem once earlier, but that was due
> to the fact that you tried to build the Fortran front end in the
> first stage build.  This does not work unless you are compiling with
> gcc.

autoconf (configure) should be used to determine if the C compiler one
is using will in fact be capable of compiling the Fortran part, if
not, it should arrange to bootstrap all by itself.

Re: testing consistency

[Jim Wilson]

	autoconf (configure) should be used to determine if the C compiler one
	is using will in fact be capable of compiling the Fortran part, if
	not, it should arrange to bootstrap all by itself.

We probably want to bootstrap regardless of which compiler is being used,
because this is how gcc builds have always worked, and because this serves
as a useful test to verify that gcc was built correctly.  I don't think
we want to autoconf this.

Jim

Re: testing consistency

[meissner]

Speaking as a Linux user, I tend to prefer it not be installed into /usr
unless I explicitly add --prefix=/usr.  None of the other tools, such
as ld, as, etc. install themselves into /usr, and in fact when I started
using Linux, I tended to get burned by it installing itself into /usr
and the assembler and friends installing themself into /usr/local, until
I started using --prefix all of the time.

Re: testing consistency

[Doug Evans]

   Date: Thu, 11 Sep 1997 18:27:14 -0400 (EDT)
   From: meissner@cygnus.com

   Speaking as a Linux user, I tend to prefer it not be installed into /usr
   unless I explicitly add --prefix=/usr.  None of the other tools, such
   as ld, as, etc. install themselves into /usr.

I agree.

   None of the other tools, such
   as ld, as, etc. install themselves into /usr.

Re: testing consistency

[Joe Buck]

Mike Meissner writes:
> Speaking as a Linux user, I tend to prefer it not be installed into /usr
> unless I explicitly add --prefix=/usr.

I agree.  The Linux user who downloads and builds egcs should be able to
have it co-exist with the "official" gcc version that is installed in
/bin.  We should not assume that the default operation is to replace the
standard compiler.

In any case, I specify --prefix every time I build a GNU tool; it's
no big deal to add --prefix=/usr when it is appropriate.

Anyway, we should not be encouraging naive Linux users (users who find
--prefix hard to understand) to immediately install the first egcs release
as their only official compiler.

> and in fact when I started
> using Linux, I tended to get burned by it installing itself into /usr
> and the assembler and friends installing themself into /usr/local, until
> I started using --prefix all of the time.

Yes, this is the main problem: the default for --prefix should be the
same for all tools, and /usr/local is as good as any.

Re: testing consistency

[not-for-mail]

>>>>> meissner  <meissner@cygnus.com> writes:

> Speaking as a Linux user, I tend to prefer it not be installed into /usr
> unless I explicitly add --prefix=/usr.

I agree.

Jason

Re: testing consistency

[Peter Seebach]

I have, for many years now, used almost nothing but systems where gcc has been
"the compiler".  On Amiga Unix, BSD/OS, NetBSD, Lynx/OS, the NeXT, and
Linux, gcc has been "the compiler" for quite some time.

I would be *very* upset if I downloaded another version, compiled it,
and found that it installed by default into /usr.

I mean, *very* upset.  It would make me very distrustful.

I had never, before this, even *considered* the possibility that something
I grab separately from my OS would try to install itself in the normal /usr;
/usr is for *unified distributions*.  I do not want anything going in /usr
unless that exact version, as built, is *exactly* the one the rest of /usr
is tested with.

I would, in any event, never want a compiler or other "base" tool to
overwrite "the system default", unless I went out of my way to tell it to.

When I build a new version of a compiler, I expect it to keep itself nicely
isolated from "the system" unless explicitly told to do otherwise; this
prevents all manner of unfortunate mishaps.

Saying "gcc is the system compiler" is deeply misleading.  Bugs creep in and
out.  Code may, however wrong this is, *depend* on a given set of bugs, or
a given set of implementation decisions.  gcc is not always the same as, or
even compatible with, gcc.  I think it's great to be *able* to replace the
system compiler with a more current version of gcc, but I think it is very
bad for that to be the default behavior.

My vote, as a regular user of several systems where gcc is "the compiler",
would be very strongly that gcc should continue to, by default, install into
/usr/local, and deciding that it should be installed into /usr should remain
an act of explicit volition, either by the user running configure, or the
person preparing a package for distribution.

Your milage may vary.  Some compilers not for use with some programs.  Your
sysadmin helps you put it together.

-s

Re: testing consistency

[Alexandre Oliva]

> The first step in this process is to get everyone to bootstrap in the
> same manner.  Is anyone else using the rough toplevel "bootstrap"
> target I posted last week?  Comments and improvements are definitely
> welcome!

I'm not using that bootstrap yet because it lacks some features I
really need:

1) the ability to specify additional flags to be used to build gcc.  I
currently have to append a strtoul-related flag to CFLAGS and
BOOT_CFLAGS so that I can build g77 on SunOS 4.1.3, and I can only do
that by using the bootstrap target in the gcc directory.

2) the ability to continue a build from a given stage on, as I can do
with bootstrap2 & bootstrap3.

Also, I don't think bootstrap should make compare.  Maybe I'm just
used to the ol' gcc bootstrap behavior, but I don't think building gcc
has anything to do with comparing it.  Maybe make check should do
it...

Here's a patch that provides bootstrap[23] targets, and removes the
BOOT_CFLAGS from the make invocation.  Doing this, BOOT_CFLAGS may be
overridden, and, if it is not, the default BOOT_CFLAGS from the gcc
Makefile will be used.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: testing consistency

[Jeffrey A Law]

  In message <oren6qtfsg.fsf@sunsite.dcc.unicamp.br>you write:
  > > The first step in this process is to get everyone to bootstrap in the
  > > same manner.  Is anyone else using the rough toplevel "bootstrap"
  > > target I posted last week?  Comments and improvements are definitely
  > > welcome!
  > 
  > I'm not using that bootstrap yet because it lacks some features I
  > really need:
  > 
  > 1) the ability to specify additional flags to be used to build gcc.  I
  > currently have to append a strtoul-related flag to CFLAGS and
  > BOOT_CFLAGS so that I can build g77 on SunOS 4.1.3, and I can only do
  > that by using the bootstrap target in the gcc directory.
I think the way to address this is to to get the magic strtoul stuff
defined automatically.  This has been in the back of my mind as a relatively
important issue to address before the release.

  > 2) the ability to continue a build from a given stage on, as I can do
  > with bootstrap2 & bootstrap3.
Certainly would be useful.


  > Also, I don't think bootstrap should make compare.  Maybe I'm just
  > used to the ol' gcc bootstrap behavior, but I don't think building gcc
  > has anything to do with comparing it.  Maybe make check should do
  > it...
We differ in our opinions.

As far as I'm concerned, _building_ gcc means 3-staging it and comparing
it (native platforms).  We need not be restricted by the old way of doing
things.

  > Here's a patch that provides bootstrap[23] targets
I've added this part, but with BOOT_CFLAGS for now.

  > and removes the
  > BOOT_CFLAGS from the make invocation.  Doing this, BOOT_CFLAGS may be
  > overridden, and, if it is not, the default BOOT_CFLAGS from the gcc
  > Makefile will be used.
I'd really prefer not to make it too easy to override BOOT_CFLAGS; remember
we want both ourselves and the average joe using egcs to build in the
same manner -- making BOOT_CFLAGS easy to override defeats that purpose to
some extent.

Jeff

Re: testing consistency

[Alexandre Oliva]

Jeffrey A Law writes:

> I'd really prefer not to make it too easy to override BOOT_CFLAGS; remember
> we want both ourselves and the average joe using egcs to build in the
> same manner -- making BOOT_CFLAGS easy to override defeats that purpose to
> some extent.

OTOH, it makes it harder to test alternate configurations, and there
are certainly people who'd like to perform tests by compiling gcc with
look unrolling (Kaveh Ghazi does, as far as I remember), higher
optimization levels (as I do), etc.  The average joe would not set
BOOT_CFLAGS at all; I think anyone who intends to perform more
complete automated testing (like me) would be interested in being able
to bootstrap gcc with different flags.

I understand your concern about making sure gcc is tested in standard
conditions, but there's no reason for making it harder to test it more
completely, is there?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: testing consistency

[Jeffrey A Law]

  In message < orlo0ulyh5.fsf@sunsite.dcc.unicamp.br >you write:
  > I understand your concern about making sure gcc is tested in standard
  > conditions, but there's no reason for making it harder to test it more
  > completely, is there?
I guess you're right.

I've taken BOOT_CFLAGS out of the toplevel Makefile.in.  In theory
you should be able to override it in the next snapshot.  Let me know
if it doesn't work.

You also shouldn't have to play the strtoul game with the next snapshot,
if it doesn't work let me know.


Jeff

Re: testing consistency

[Mike Stump]

> As far as I'm concerned, _building_ gcc means 3-staging it and comparing
> it (native platforms).  We need not be restricted by the old way of doing
> things.

I think it is reasonable to consider comparing as part of the checking
process.  Right now, make doesn't imply make check.  I can envision a
change in make, so that check is in fact implied.  make && make
install then has neat interesting semantics.

I think I would rather see comparing as part of the check process, and
we should just encourage people to do make check.  Maybe make check is
appropriate to add to the end of a bootstrap?

Re: testing consistency

[Jeffrey A Law]

  In message < 199709190442.VAA17154@kankakee.wrs.com >you write:
  > I think it is reasonable to consider comparing as part of the checking
  > process.
I strongly disagree.  The GCC installation instructions have always said
to 3-stage and compare the compiler -- by using a series of make targets ie.

make LANGUAGES=c
make stage1
make CC="stage1/xgcc -O2 -g -Bstage1" 
make stage2
etc etc


What we're doing is making that basic build simpler and less error
prone (how many remember when different CFLAGS were in the instructions
for the stage2 and stage3 build?)

  > Right now, make doesn't imply make check.  I can envision a
  > change in make, so that check is in fact implied.  make && make
  > install then has neat interesting semantics.
I'd recommend against that until we see how many people are actually
interested in sucking down and running the testsuite.

Jeff

Re: testing consistency

[Joe Buck]

> I think it is reasonable to consider comparing as part of the checking
> process.  Right now, make doesn't imply make check.  I can envision a
> change in make, so that check is in fact implied.  make && make
> install then has neat interesting semantics.

The full "make check" takes too long, so it's not a bad idea to enforce
it.  However, if a three-stage build has already been done, make compare
is trivial, so we might as well do it.

Re: testing consistency

[Kaveh R. Ghazi]

 > Jeffrey A Law writes:
 > 
 > > I'd really prefer not to make it too easy to override BOOT_CFLAGS;
 > > remember we want both ourselves and the average joe using egcs to build
 > > in the same manner -- making BOOT_CFLAGS easy to override defeats that
 > > purpose to some extent.
 > 
 > OTOH, it makes it harder to test alternate configurations, and there
 > are certainly people who'd like to perform tests by compiling gcc with
 > look unrolling (Kaveh Ghazi does, as far as I remember), higher
 > optimization levels (as I do), etc.  The average joe would not set
 > BOOT_CFLAGS at all; I think anyone who intends to perform more
 > complete automated testing (like me) would be interested in being able
 > to bootstrap gcc with different flags.
 > 
 > I understand your concern about making sure gcc is tested in standard
 > conditions, but there's no reason for making it harder to test it more
 > completely, is there?
 > -- 
 > Alexandre Oliva
 
	I completely agree.

	I've always considered it a bad practice that up until
recently configuring any package with autoconf passed only -g -O to
gcc.  Ditto for BOOT_CFLAGS when building gcc.  Cheers to whoever had
enough faith in gcc to up the default CFLAGS produced by autoconf. :-)

	Its great that -O2 is used by default now.  But if we don't
test the >O2 opts more, we can't expect them to get safe enough to
use.  Okay, maybe they're avoided because they don't always produce
better code, but I think they're also marginalized because of the
perception that they aren't ready for prime time.  We can't change
this except by using them.

	I'd urge _more_ testing with higher BOOTCFLAGS.  Eg, inline
functions are very important in c++.  We should be testing -O3 or
-finline-functions more.

	To make testing easier and encourage more usage, I'd like to
see a -Oall with every possible optimization flag thrown in.  (I can
agree that choosing -funroll-loops vs. -funroll-all-loops is
debatable.)  Maybe a new -O4 contains -funroll-loops and -Oall
contains -funroll-all-loops.  I can provide a patch if this is desired.

		Comments?
		--Kaveh
--
Kaveh R. Ghazi				Project Manager
ghazi@caip.rutgers.edu			ICon CMT Corp.

Re: testing consistency

[Joe Buck]

> 	Its great that -O2 is used by default now.  But if we don't
> test the >O2 opts more, we can't expect them to get safe enough to
> use.

I agree *but* -- we must make sure that there is a set of flags that
is thoroughly and consistently tested.  I have no problem with people
running tests and fixing problems with other combinations, *as long as*
we have tests with "-g -O2" for as many platforms as possible.  Given
the exponential blowup in the number of possible combinations of flags,
we can pretty much guarantee that certain combinations of flags are
likely to produce a buggy gcc executable, so we also want to be able
to recommend to the public that they compile gcc with the flags we've
done the most testing on.