2 (small?) problems

2 (small?) problems

[Thomas Hiller]

Hello,

I encountered 2 problems with the current snapshot (beside some others already 
mentioned on the list).

1)	c++filt is not installed.

2)	Shared libg++ problem.
	I have a problem (also with the normal gcc), when I install the compiler
	in a non-standard place (e.g. /work/egcs). The shared libg++ is not
	found. I had to set the LD_LIBRARY_PATH to include $prefix/lib. Is there
	a portable way to set the shared library path from the compiler ? The
	compiler already issues -L$prefix/lib.
	
Greetings
	Thomas

Thomas Hiller				email: hiller@tu-harburg.d400.de
TU Hamburg-Harburg
Zentrallabor Informations- und Kommunikationstechnik
Harburger Schloss-Str. 20		Tel.: +49-40-7718-3448
D - 21071 Hamburg			Fax : +49-40-7718-2579

Re: GCC Projects?

[Bernd Schmidt]

> 
> I wouldn't lose sleep if it just disappeared one day.

I'd be happy to provide a patch to make it disappear. Do you want one?

Bernd

Re: prototyping

[Andi Kleen]

Per Bothner <bothner@cygnus.com> writes:

> > One of the things we should be doing -- switching to cpplib across
> > the board instead of for just the fixing of header files.
> > 
> > Per, are there any technical reasons why we can't start this soon?
> 
> There is no particular reason why we cannot switch from cpp compiled
> from cccp.c to one compiled from cpplib.c+cpplib.c.  Just change
> CCCP=ccccp to CCCP=cppmain in the Makefile.  However, there are
> years of changes to cccp made after cpplib was forked off that have
> not been merged into cpplib.  It would great if we could have a volunteer
> go through the RCS files for cccp.c and cexp.y, evaluate the changes,
> and integrate them into cpplib.c and cppexp.c.  In the case of changes
> where it is non-obvious how to make them in cpplib, I'd be happy to
> advice or even write the changes.  What I do not have time for is
> the tedious task of sifting through the changes, making the easy
> patches, and flagging the difficult ones.

I would be happy to do at least some of this work of sifting through
the RCS files. Are they available somewhere?


-Andi

Will egcs support MachTen?

[N8TM]

I have been following g77 alpha successfully on MachTen 4.03.  In view of the
interest in merging g77 alpha and egcs work, I'd like to know if egcs can be
made to work on MachTen.  I spent a few hours at it yesterday without
success.
Tim

Re: front end interface

[Clive Nicolson]

>> I've mentioned this in private email but I should let the list know as
>> well: my alias code in the back end recognizes certain C function names.
>> I believe this is correct because all languages will be linking with the C
>> library and must mangle or prohibit any names which conflict.  For example,
>> Fortran symbols traditionally have a "_" added to the end.
>> 
>If I understand this correctly, you're depending on memcpy() being named 'memcpy' ?!
>
>This leads into trouble with the current openVMS ports (vax and alpha), where most
>library functions are '#define'd with a DECC$ in front (and others have a __asm() appended
>to their declaration). So the compiler doesn't see memcpy but DECC$MEMCPY.

This is somewhat in violation of the ANSI C rules about names. I have a patched version
of gcc 2.7.1 (vax vms) that translates ANSI C names (to those found in the DEC
runtime libraries) in the assembler, this is much like that done by DEC's DECC compiler.

I still have to fix the passing of some attributes via the name prefixing hack used by
gcc vax/vms.

Clive.

Re: [EGCS] Re: double alignment patch for x86

[Dave Love]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

 >> It takes 2 additional cycles per double access.. this can sum up
 >> to 30% runtime penalty on important algorithms like matrix
 >> multiply...

 Toon> This is on a Pentium ?  

It's about right for daxpy on my pentium.

-- Dave (recycled physicist)

Re: prototyping

[Per Bothner]

  > I would be happy to do at least some of this work of sifting through
  > the RCS files.

What I would suggest is:
	rlog cccp.c >cccp.c.log
	rlog cexp.y >cexp.y.log

Then go through the logs, looking at anything after cpplib was forked off
(late 94 or early 95).  (The cpplib.c log notes that 1995/03/22 I merged
in various changes from late 94 and early 95, so it looks like cpplib
was forked off in mid-to-late 94.)

For every change in the log entry, use rcsdiff -cp to examine the change.
Annotate the log to mark changes that are already in cpplib, or that
don't need to be in cpplib;  for changes that are still needed,
ether make a patch (and send it to me and Jeff Law), or make an annotation
in the log that the change still needs to be considered, or ask me
for advice.  (Note that in some cases changes may be irrelevant because
of later changes, so check that the change is still in cccp.c/cexp.y
before trying to re-implement it!)

I started doing this, but now I can't find my old annotated log.
In any case, I didn't get very far.  Note that if you maintain an
annotated rcs log, you can keep track of progress.  Also, if the job
takes too much time, you can share it with someone else, or you can
hand it over, as long as you have annotated rcs log files to keep
track what has been done, and what still needs to be done.

One major set of performance improvements to cccp.c was checked in
Dec 17 1995.  It would be nice nice to get that in, but it is probably
best to wait until you understand cpplib.c reasonably well.

For testing, note that the cppmain program is meant to be plug-compatible
with cpp.  (There might be some differences, such as column numbers in
error messasges, or a few whitespace changes in eh output, but there
should be nothing significant.)  (My goal is that cpplib should
insert fewer unncessary token-separating whitespace than cpp.)

Thanks for taking this on!

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

Re: 2 (small?) problems

[Jim Meyering]

Fergus Henderson <fjh@cs.mu.oz.au> writes:
| Thomas Hiller, you wrote:
| > 2)	Shared libg++ problem.
| > 	I have a problem (also with the normal gcc), when I install the compiler
| > 	in a non-standard place (e.g. /work/egcs). The shared libg++ is not
| > 	found. I had to set the LD_LIBRARY_PATH to include $prefix/lib. Is there
| > 	a portable way to set the shared library path from the compiler ? The
| > 	compiler already issues -L$prefix/lib.
|
| As far as I'm aware there's no portable way.  Depending on the system,
| you use either `-rpath' or `-R', and depending on the system, multiple
| directories must either be specified as separate options, or a
| colon-separated path must be specified as a single option.

The way to insulate egcs from this portability problem is to convert
it to use GNU libtool.  See

  ftp://prep.ai.mit.edu/pub/gnu/libtool-1.1.tar.gz

If egcs is serious about building/installing shared libraries,
someone should add this to the projects list.

Re: 2 (small?) problems

[Fergus Henderson]

Thomas Hiller, you wrote:
> 2)	Shared libg++ problem.
> 	I have a problem (also with the normal gcc), when I install the compiler
> 	in a non-standard place (e.g. /work/egcs). The shared libg++ is not
> 	found. I had to set the LD_LIBRARY_PATH to include $prefix/lib. Is there
> 	a portable way to set the shared library path from the compiler ? The
> 	compiler already issues -L$prefix/lib.

As far as I'm aware there's no portable way.  Depending on the system,
you use either `-rpath' or `-R', and depending on the system, multiple
directories must either be specified as separate options, or a
colon-separated path must be specified as a single option.

On sparc-sun-solaris, use multiple -R options (e.g. `-Rdir1 -Rdir2').
On i586-linux-pc-gnu, use multiple -rpath options (`-rpath dir1 -rpath dir2').
On alpha-dec-osf and mips-sgi-irix, use a single -rpath option
(e.g. `-rpath dir1:dir2').

Really this nonportability is something that gcc should encapsulate,
just as `gcc -shared' encapsulates (some of) the non-portable aspects
of creating shared libraries on different systems.  gcc ought to
recognize `-rpath' on all these systems, and it should handle the
accumulation of multiple `-rpath' options into a single colon-separated
path for the linker on alpha-dec-osf and mips-sgi-irix.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: 2 (small?) problems

[Ian Lance Taylor]

   From: Fergus Henderson <fjh@cs.mu.oz.au>
   Date: Tue, 19 Aug 1997 03:49:55 +1000 (EST)

   On i586-linux-pc-gnu, use multiple -rpath options (`-rpath dir1 -rpath dir2').

The GNU linker used on Linux also supports multiple -R options as well
as -R or -rpath options with a path.

   Really this nonportability is something that gcc should encapsulate,
   just as `gcc -shared' encapsulates (some of) the non-portable aspects
   of creating shared libraries on different systems.  gcc ought to
   recognize `-rpath' on all these systems, and it should handle the
   accumulation of multiple `-rpath' options into a single colon-separated
   path for the linker on alpha-dec-osf and mips-sgi-irix.

Note that the libtool package already helps to handle these and other
shared library issues.

Ian

Re: 2 (small?) problems

[Jim Wilson]

	1)	c++filt is not installed.

It turns out that c++filt is in both binutils and gcc2/egcs.  It is being
installed, but it is the binutils one that gets installed, not the gcc2/egcs
one.  It would be wrong to install both of them, so we can't install it from
gcc2/egcs.

Eventually, c++filt should be removed from one of these packages, but I am
not going to worry about this for now.

Jim