once we have cpplib...

once we have cpplib...

[Ulrich Drepper]

Hi,

there is lately some motion to get cpplib finally used in gcc.  Once
this is done we have several more options and I think we should plan
on them now.

- with cpplib it'll be possible for the compiler to get the hands on the
  the macro definitions.  This will

  * allow to emit debug info about macros which can be disaplyed in gdb
    when DWARF is used

  * finally allow to use the debugger on code in macros since the line
    number information is available

- since cpplib will (should) provide the compiler the already tokenized
  stream there are no more # lines, esp no #pragma lines.  I.e., there
  must be a hook for pragmas.  This will be esp important with ISO C 9X
  where much of the math code optimization depends on this.

- cpplib must be in sync with the current cccp.  I think Paul did it most
  of the time but is everything included?

- we need a way to allow old gcc drivers call new backends and vice versa.
  Probably this can be achieved by adding some more specs file entries.

Comment on this?  Any points I forgot?

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: once we have cpplib...

[Per Bothner]

> - since cpplib will (should) provide the compiler the already tokenized
>   stream there are no more # lines, esp no #pragma lines.

We could either configure cpplib to pass the #pragma to the C/C++ lexer,
or (perhaps more efficient) we could defined some kind of call-back
from cpplib to the lexer.

> - cpplib must be in sync with the current cccp.  I think Paul did it most
>   of the time but is everything included?

Very few cccp changes later than sometime in 1995 or 96 are in cpplib.

This is the part that is going to take time.  I don't know if this
work has been scheduled.

> - we need a way to allow old gcc drivers call new backends and vice versa.
>  Probably this can be achieved by adding some more specs file entries.

Persnally, I don't see this as having much importance.  Do we we really
support the -V option?  Cygnus has always recommended against its use.

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

Re: once we have cpplib...

[Andreas Schwab]

Ulrich Drepper <drepper@cygnus.com> writes:

|> - since cpplib will (should) provide the compiler the already tokenized
|>   stream there are no more # lines, esp no #pragma lines.  I.e., there
|>   must be a hook for pragmas.  This will be esp important with ISO C 9X
|>   where much of the math code optimization depends on this.

C9X introduces the pragma operator _Pragma("...") to put pragmas inline.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: once we have cpplib...

[Ulrich Drepper]

Andreas Schwab <schwab@issan.informatik.uni-dortmund.de> writes:

> C9X introduces the pragma operator _Pragma("...") to put pragmas inline.

Yes, but #pragma must still be recognized and _Pragma is chosen to
allow the definition of _Pragmas using #define.  _Pragma will very
early be transformed into #pragma .

Per and Dave suggested to simply have an appropriate call-back the
backend has to provide.  This is the common practive in other
compilers.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: once we have cpplib...

[Ulrich Drepper]

bothner@cygnus.com (Per Bothner) writes:

> Persnally, I don't see this as having much importance.  Do we we really
> support the -V option?  Cygnus has always recommended against its use.

I think it is essential.  I have many old compilers lying around since
I build and install egcs frequently.  If a version is broken I must be
easy to use an old version.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: once we have cpplib...

[Joe Buck]

> > Persnally, I don't see this as having much importance.  Do we we really
> > support the -V option?  Cygnus has always recommended against its use.
> 
> I think it is essential.  I have many old compilers lying around since
> I build and install egcs frequently.  If a version is broken I must be
> easy to use an old version.

Unfortunately -V switches compilers but doesn't switch libstdc++, so
in practice I've had to use distinct --prefix values to keep multiple
compilers around.

Re: once we have cpplib...

[Jeffrey A Law]

  In message < 199804100044.RAA11888@atrus.synopsys.com >you write:
  > > > Persnally, I don't see this as having much importance.  Do we we really
  > > > support the -V option?  Cygnus has always recommended against its use.
  > > 
  > > I think it is essential.  I have many old compilers lying around since
  > > I build and install egcs frequently.  If a version is broken I must be
  > > easy to use an old version.
  > 
  > Unfortunately -V switches compilers but doesn't switch libstdc++, so
  > in practice I've had to use distinct --prefix values to keep multiple
  > compilers around.
So, I'll bring it up again, do we want to move the g++ header
files and libraries into $libsubdir?

We've discussed it at length in the past; I don't remember ever
reaching any decision.


jeff

Re: once we have cpplib...

[John Polstra]

In article < 29460.892182063@hurl.cygnus.com >,
Jeffrey A Law  <law@cygnus.com> wrote:

>   > Unfortunately -V switches compilers but doesn't switch libstdc++, so
>   > in practice I've had to use distinct --prefix values to keep multiple
>   > compilers around.
> So, I'll bring it up again, do we want to move the g++ header
> files and libraries into $libsubdir?

Yes yes yes yes yes yes yes.  The way it's done currently is really
a pain for those who want to have more than one gcc-like compiler
installed.
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth

Re: once we have cpplib...

[Manfred Hollstein]

On Thu, 9 April 1998, 22:21:03, law@cygnus.com wrote:

 > 
 >   In message < 199804100044.RAA11888@atrus.synopsys.com >you write:
 >   > > > Persnally, I don't see this as having much importance.  Do we we really
 >   > > > support the -V option?  Cygnus has always recommended against its use.
 >   > > 
 >   > > I think it is essential.  I have many old compilers lying around since
 >   > > I build and install egcs frequently.  If a version is broken I must be
 >   > > easy to use an old version.
 >   > 
 >   > Unfortunately -V switches compilers but doesn't switch libstdc++, so
 >   > in practice I've had to use distinct --prefix values to keep multiple
 >   > compilers around.
 > So, I'll bring it up again, do we want to move the g++ header
 > files and libraries into $libsubdir?
 > 
 > We've discussed it at length in the past; I don't remember ever
 > reaching any decision.

I'd greatly appreciate  if the stuff will  be installed in $libsubdir,
because this is the way I've installed it since gcc-2.2.2 (or so).

If we'll be going to change installation rules, where should
_G_config.h be installed? Currently it goes into
${prefix}/${target}/include, but I think it should be installed in
${libsubdir}/include (or ${gxx_include_dir}), right?!

Anyway, if nobody  else has a patch already  I'll preparing  one which
will provide this:

  1. Change the default for g++ header installation from
     ${prefix}/include/g++ to ${libsubdir}/include/g++
  2. Install _G_config.h in ${libsubdir}/include.
  3. Install runtime libs (libstdc++.*) in ${libsubdir}
     resp. subdirectories for multilib configurations.

Once  3. is active,  I'm afraid we'll be  receiving lots of complaints
from Linux users  about   ld.so no  longer   finding libstdc++.so.2.8,
though :-(

This brings back the `-rpath'  question. How about gcc/collect2 adding
it if libstdc++.so is found via one of the `standard directories' from
the specs file?

manfred

Re: once we have cpplib...

[H.J. Lu]

> 
> On Thu, 9 April 1998, 22:21:03, law@cygnus.com wrote:
> 
>  > 
>  >   In message < 199804100044.RAA11888@atrus.synopsys.com >you write:
>  >   > > > Persnally, I don't see this as having much importance.  Do we we really
>  >   > > > support the -V option?  Cygnus has always recommended against its use.
>  >   > > 
>  >   > > I think it is essential.  I have many old compilers lying around since
>  >   > > I build and install egcs frequently.  If a version is broken I must be
>  >   > > easy to use an old version.
>  >   > 
>  >   > Unfortunately -V switches compilers but doesn't switch libstdc++, so
>  >   > in practice I've had to use distinct --prefix values to keep multiple
>  >   > compilers around.
>  > So, I'll bring it up again, do we want to move the g++ header
>  > files and libraries into $libsubdir?
>  > 
>  > We've discussed it at length in the past; I don't remember ever
>  > reaching any decision.
> 
> I'd greatly appreciate  if the stuff will  be installed in $libsubdir,
> because this is the way I've installed it since gcc-2.2.2 (or so).
> 
> If we'll be going to change installation rules, where should
> _G_config.h be installed? Currently it goes into
> ${prefix}/${target}/include, but I think it should be installed in
> ${libsubdir}/include (or ${gxx_include_dir}), right?!

We have to be very careful on it.

> 
> Anyway, if nobody  else has a patch already  I'll preparing  one which
> will provide this:
> 
>   1. Change the default for g++ header installation from
>      ${prefix}/include/g++ to ${libsubdir}/include/g++
>   2. Install _G_config.h in ${libsubdir}/include.
>   3. Install runtime libs (libstdc++.*) in ${libsubdir}
>      resp. subdirectories for multilib configurations.
> 
> Once  3. is active,  I'm afraid we'll be  receiving lots of complaints
> from Linux users  about   ld.so no  longer   finding libstdc++.so.2.8,
> though :-(
> 

I have warned it many months ago.

-- 
H.J. Lu (hjl@gnu.org)

New installation defaults (was: Re: once we have cpplib...)

[Manfred Hollstein]

On Thu, 16 April 1998, 15:07:18, hjl@lucon.org wrote:

 [snip]
 > > If we'll be going to change installation rules, where should
 > > _G_config.h be installed? Currently it goes into
 > > ${prefix}/${target}/include, but I think it should be installed in
 > > ${libsubdir}/include (or ${gxx_include_dir}), right?!
 > 
 > We have to be very careful on it.
 > 
 > > 
 > > Anyway, if nobody  else has a patch already  I'll preparing  one which
 > > will provide this:
 > > 
 > >   1. Change the default for g++ header installation from
 > >      ${prefix}/include/g++ to ${libsubdir}/include/g++
 > >   2. Install _G_config.h in ${libsubdir}/include.
 > >   3. Install runtime libs (libstdc++.*) in ${libsubdir}
 > >      resp. subdirectories for multilib configurations.
 > > 
 > > Once  3. is active,  I'm afraid we'll be  receiving lots of complaints
 > > from Linux users  about   ld.so no  longer   finding libstdc++.so.2.8,
 > > though :-(
 > > 
 > 
 > I have warned it many months ago.

Agreed, I think if we'll be going to change installation defaults, we
should agree which way to go!

So, the questions look to me like:

1. Shall we change the installation defaults?

If yes:

 2. Where shall _G_config.h be installed?

    a) in ${libsubdir}/include
    b) in ${gxx_include_dir}

 3. How do we manage locating a shared libstdc++ at runtime if their
    location changes from a directory covered by /etc/ld.so.conf to a
    new absolutely non-standard one?

If not:

 4. How do we achieve to help people protect their `standard'
    installation from being clobbered by an `experimental' one and
    without introducing too many --prefix=.../package/... related
    directories?

I'm sorry if you feel bothered by this, but I agree with H.J.:

  the current situation isn't very pleasant with having two worlds
  competing: most Linux users able to get root access allowing them to
  add any possible directory to ld.so's cache, and the rest of the world
  (I really hate to always type something like the following on
   Solaris: "g++ ... -Wl,-rpath,`gcc --print-file-name=`"!).

So, what's your vote?

manfred

Re: New installation defaults (was: Re: once we have cpplib...)

[H.J. Lu]

> 
> Agreed, I think if we'll be going to change installation defaults, we
> should agree which way to go!
> 
> So, the questions look to me like:
> 
> 1. Shall we change the installation defaults?
> 
> If yes:
> 
>  2. Where shall _G_config.h be installed?
> 
>     a) in ${libsubdir}/include

It may be ok for egcs, but not for a standalone libstdc++.

>     b) in ${gxx_include_dir}

I prefer this one since libstdc++ is not installed in
${libsubdir}.

> 
>  3. How do we manage locating a shared libstdc++ at runtime if their
>     location changes from a directory covered by /etc/ld.so.conf to a
>     new absolutely non-standard one?
> 
> If not:
> 
>  4. How do we achieve to help people protect their `standard'
>     installation from being clobbered by an `experimental' one and
>     without introducing too many --prefix=.../package/... related
>     directories?
> 
> I'm sorry if you feel bothered by this, but I agree with H.J.:
> 
>   the current situation isn't very pleasant with having two worlds
>   competing: most Linux users able to get root access allowing them to
>   add any possible directory to ld.so's cache, and the rest of the world
>   (I really hate to always type something like the following on
>    Solaris: "g++ ... -Wl,-rpath,`gcc --print-file-name=`"!).
> 

Give user a choice at the configure time.

-- 
H.J. Lu (hjl@gnu.org)

Re: once we have cpplib...

[Martin von Loewis]

> Unfortunately -V switches compilers but doesn't switch libstdc++, so
> in practice I've had to use distinct --prefix values to keep multiple
> compilers around.

We routinely install libg++/libstdc++ together with the compiler, so
we can switch between compiler versions easily using -V. Of course,
the procedure of installing libg++, and telling g++ where to find it
has changed several times since 2.5.0.

Regards,
Martin

Re: once we have cpplib...

[Jeffrey A Law]

  In message < r2hg43eyby.fsf@happy.cygnus.com >you write:
  > bothner@cygnus.com (Per Bothner) writes:
  > 
  > > Persnally, I don't see this as having much importance.  Do we we really
  > > support the -V option?  Cygnus has always recommended against its use.
  > 
  > I think it is essential.  I have many old compilers lying around since
  > I build and install egcs frequently.  If a version is broken I must be
  > easy to use an old version.
So we have gcc.c look in $(libsubdir) for cpp.  If it finds it, then
it invokes the passes in the old way (cpp, cc1).  If no cpp is found
then it assumes that we have an integrated cpp & cc1.

jeff

Re: once we have cpplib...

[Per Bothner]

> So we have gcc.c look in $(libsubdir) for cpp.  If it finds it, then
> it invokes the passes in the old way (cpp, cc1).

That implies we do not want a standa-alone cpp executable.
(Cpplib linked with a trivial main program cppmain provides basically
the functionality of the standalone cpp.)

While doing (yet) another stat is a minor cost, still it seems
wasteful.

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

Re: once we have cpplib...

[Joern Rennecke]

> > So we have gcc.c look in $(libsubdir) for cpp.  If it finds it, then
> > it invokes the passes in the old way (cpp, cc1).
> 
> That implies we do not want a standa-alone cpp executable.
> (Cpplib linked with a trivial main program cppmain provides basically
> the functionality of the standalone cpp.)
> 
> While doing (yet) another stat is a minor cost, still it seems
> wasteful.

Well, assuming the usual case is that the gcc is invoked without -V ,
we could make a special case for this and skip the check for an existing
cpp.  Or we could even check the version given against the smallest
gcc version that is known to have an integrated cpp/cc1.

Re: once we have cpplib...

[Ulrich Drepper]

amylaar@cygnus.co.uk (Joern Rennecke) writes:

> Or we could even check the version given against the smallest
> gcc version that is known to have an integrated cpp/cc1.

I don't think this is possible since the internal names might be
chosen by the installer.  I did this quite a long time so that I can
keep multiple gcc versions around though the given version numbers are
the same.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: once we have cpplib...

[Jeffrey A Law]

  In message < r24t04i3n9.fsf@happy.cygnus.com >you write:
  > there is lately some motion to get cpplib finally used in gcc.  Once
  > this is done we have several more options and I think we should plan
  > on them now.
Yup.  In fact, I just checked in the first group of changes from Dave
to move us in that direction.

  > - with cpplib it'll be possible for the compiler to get the hands on the
  >   the macro definitions.  This will
  > 
  >   * allow to emit debug info about macros which can be disaplyed in gdb
  >     when DWARF is used
  > 
  >   * finally allow to use the debugger on code in macros since the line
  >     number information is available
Yup.  Big win, especially for those of us how debug gcc where big
macros are far too common :( 


  > - cpplib must be in sync with the current cccp.  I think Paul did it most
  >   of the time but is everything included?
Probably not.  Someone will have to go through each change to cccp
to make sure it's in cpplib.  Not pleasant, but necessary.

  > - we need a way to allow old gcc drivers call new backends and vice versa.
  >   Probably this can be achieved by adding some more specs file entries.
Well, I find -V a nice thing to have, but I don't mind breaking it
for something this significant.  Or just make cpp a trivial program
that calls gcc with the right arguments to put it into "cpp" mode :-)

  > Comment on this?  Any points I forgot?
We'll still want "-save-temps" to dump out the .i file of preprocessed
output.  Probably other minor nits that we've both forgotten.

jeff

Re: once we have cpplib...

[Ulrich Drepper]

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

> Well, I find -V a nice thing to have, but I don't mind breaking it
> for something this significant.  Or just make cpp a trivial program
> that calls gcc with the right arguments to put it into "cpp" mode :-)

I think there is an easy way to keep compatibility.  When the
integrated cpp is supposed to be used give cc1 (cc1plus, ...) an extra
argument.  This is of course in the specs file.  Without the extra
argument preprocessed input is assumed.  With the argument use the
builtin cpplib.  This piece of information shouldn't be part of the
regular options but in a new category which is simply ignored by old
drivers.  Say, add

*cpplib:
-use-cpplib

to the specs file and make gcc/g77/... use this field whenever
preprocessing is necessary.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: once we have cpplib...

[Per Bothner]

> I think there is an easy way to keep compatibility.  When the
> integrated cpp is supposed to be used give cc1 (cc1plus, ...) an extra
> argument.

The main difference between cc1 needs to know whether it should
pre-process the input is if it sees an identifier that matches a builtin
macro - should that be expanded or not?  Since such macros tend to be
in the implementor's name-space, I can't think of valid code which would
be harmed by having cc1 do the macro-expansion, even if it already was
processed by cpp.

But there is an easy way cc1 can tell if the input was already
processed by cpp:  Look at the first line.  If it looks like:
	# 1 "foo.c"
then it is cpp output, since such a line is not a valid
pre-processor directive, I believe.

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

Re: once we have cpplib...

[Dave Brolley]

Per Bothner wrote:

> The main difference between cc1 needs to know whether it should
> pre-process the input is if it sees an identifier that matches a builtin
> macro - should that be expanded or not?  Since such macros tend to be
> in the implementor's name-space, I can't think of valid code which would
> be harmed by having cc1 do the macro-expansion, even if it already was
> processed by cpp.

I agree with this opinion. The compilers I have worked on that had had an
integrated preprocessor never bothered to check and I don't recall seeing any
problems along these lines.

> But there is an easy way cc1 can tell if the input was already
> processed by cpp:  Look at the first line.  If it looks like:
>         # 1 "foo.c"
> then it is cpp output, since such a line is not a valid
> pre-processor directive, I believe.

It's accepted by many older compilers/preprocessors.

Dave