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

[Jeffrey A Law]

  In message <k2203rvs4u.fsf@zero.aec.at>you write:
  > > 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?
Yea.  I can get them for you.

ftp.cygnus.com:/pub/egcs/cpplibstuff.tar.gz

Has the RCS files for cccp.c, cexp.y and a couple of the cpplib files.

Good luck!

Jeff

Re: prototyping

[Jeffrey A Law]

  In message <m0x0DZq-0004ecC@ocean.lucon.org>you write:
  > It is not that simple. gcc is not designed with prototyping in mind.
  > It is kind of screwed up in that regard. A simple example, try to
  > prototype expand_expr () and you will see what I mean. It is just
  > the beginning :-).
Then skip those which are "hard" during the first pass.

At this stage it doesn't have to be 100% complete -- if we get proper
prototypes in for the majority of the functions, then we've made
significant progress.

You can then go back and work on the harder ones such as expand_expr.

Doing it this way will also mean that it'll be easier to review the
harder ones like expand_expr later.



Jeff

Re: prototyping

[H.J. Lu]

> 
>   In message <m0x0C8V-0004ecC@ocean.lucon.org>you write:
>   > > 
>   > >   In message <m0x07ER-0004ecC@ocean.lucon.org>you write:
>   > >   > I am thinking the other way around since I have removed those
>   > >   > incomplete external function declarations in .c files, using the
>   > >   > ones in .h files instead. I will first send in patches for .h files,
>   > >   > then .c files.
>   > > That's just as good of a place to start.
>   > > 
>   > 
>   > It dosen't work very well.
> I don't see why.
> 
> Go into a .c file, remove all the prototypes for extern things and
> put them into an appropriate .h file.  Remove all other prototypes
> for those same things from other .c files.
> 

It is not that simple. gcc is not designed with prototyping in mind.
It is kind of screwed up in that regard. A simple example, try to
prototype expand_expr () and you will see what I mean. It is just
the beginning :-).

I will see what I can do.


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

Re: prototyping

[H.J. Lu]

> 
>   In message <m0x07ER-0004ecC@ocean.lucon.org>you write:
>   > I am thinking the other way around since I have removed those
>   > incomplete external function declarations in .c files, using the
>   > ones in .h files instead. I will first send in patches for .h files,
>   > then .c files.
> That's just as good of a place to start.
> 

It dosen't work very well. There are so many inter-dependencies among
.h files as well as .h and .c files. Since there are no major code
changes in my prototype patch, maybe it is a better idea for me to
create a jumbo patch. Someone may just have to take a few hours to
double check my changes before checking them in. I know it is a tedious
job. But at least you don't have to worry about if I changed any code
logic. I think it is worth it.


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

Re: prototyping

[Jeffrey A Law]

  In message <m0x0C8V-0004ecC@ocean.lucon.org>you write:
  > > 
  > >   In message <m0x07ER-0004ecC@ocean.lucon.org>you write:
  > >   > I am thinking the other way around since I have removed those
  > >   > incomplete external function declarations in .c files, using the
  > >   > ones in .h files instead. I will first send in patches for .h files,
  > >   > then .c files.
  > > That's just as good of a place to start.
  > > 
  > 
  > It dosen't work very well.
I don't see why.

Go into a .c file, remove all the prototypes for extern things and
put them into an appropriate .h file.  Remove all other prototypes
for those same things from other .c files.

Submit patch.

Repeat for another .c file.


This is _much_ easier to understand and verify than a jumbo patch.

Jeff

Re: prototyping

[Jeffrey A Law]

  In message <m0x07ER-0004ecC@ocean.lucon.org>you write:
  > I am thinking the other way around since I have removed those
  > incomplete external function declarations in .c files, using the
  > ones in .h files instead. I will first send in patches for .h files,
  > then .c files.
That's just as good of a place to start.

jeff

Re: prototyping

[Per Bothner]

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

There are a few unimplemented features in cpplib.c that are needed before
it can be the default (of a production gcc).  See the TODO list at the
end of cpplib.c.  The most tricky is trigraphs - and maybe also digraphs.

Of course the big pay-off from cpplib is when it is integrated into the
lexers for languages that use it.  The most obvious win is faster
compile times.  Another potential advantage is error messages and debug
information that contain column numbers as well as line numbers.  (This
is impractical with a separate cpp, because you don't know how column
positions were adjusted by comments and macros.)  If you try cppmain
with a macro with the wrong number of arguments, you will see that the
error message contains the column number as well a the line number.

I've made most of the necessary changes to the C and ObjC lexer
(controlled by USE_CPPLIB), but have not done anything with C++.
The main thing still missing is that the gcc.c specs must be modified to
not invoke cpp, and to pass the cpp command-line arguments (such
as -I and -D) to cc1 and cc1plus.  And then toplev.c must be modified
to pass those flags to the language front-end (specifically the lexer).
So we need an API to do that.  Of course this opens the door for
arbitrary front-end specific flags, which RMS does not want.

I wrote a *teeny* bit of docuemntation that is not checked in,
including a very short cpplib.texi, appended below.

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

\input texinfo.tex      @c -*-texinfo-*-
@c %**start of header
@setfilename cpplib.info
@settitle The GNU C Pre-Processor Library
@setchapternewpage off
@c %**end of header

@iftex
@finalout
@end iftex
@titlepage
@title The CPP Library
@end titlepage

@ifinfo
@node Top, , (dir), (dir)
@top
@end ifinfo

@menu
* Output Buffer::  The Output Buffer
@end menu

@node Output Buffer
@chapter The Output Buffer

A cpp_reader contains an output buffer.  Each calls to cpp_get_token
appends the resulting text to the output buffer.  The output buffer
is also used for many purposes internally in cpplib.

@deffn Macro CPP_OUT_BUFFER (cppfile)
Returns the beginning of the output buffer (as an (unsigned char*)).
@end deffn

@deffn Macro CPP_WRITTEN (cppfile)
Returns the number of characters in @var{cppfile}'s output buffer.
@end deffn

@deffn Macro CPP_PWRITTEN (cppfile)
A pointer to the next available (unused) character in @var{cppfile}'s
output buffer.
Same as CPP_OUT_BUFFER(@var{cppfile})+CPP_WRITTEN(@var{cppfile}).
@end deffn

@deffn Macro CPP_RESERVE (cppfile, n)
Make sure the output buffer has room for at least @var{n} more characters
(beyond @code{CPP_PWRITTEN(@var{cppfile})}).
This will re-allocate the output buffer if needed.
@end deffn

The following functions append a character or a string to the output
buffer.  CPP_WRITTEN gets increased by the number of characters appended.
The macros ending in _Q do not test that there is sufficient space.
The other macros calls CPP_RESERVE to make sure there is enough space.

@deffn Macro CPP_PUTC (cppfile, ch)
Append character @var{CH} to the output buffer,
making sure there is enough space available in the output buffer.
@end deffn


@deffn Macro CPP_PUTC_Q (cppfile, ch)
Append character @var{CH} to the output buffer.
Assumes there is enough space available.
@end deffn

@deffn Macro CPP_PUTS (cppfile, str, n)
Append the string @var{str} (whose length is @var{n}) to the output buffer,
making sure there is enough space.
@end deffn

@deffn Macro CPP_PUTS_Q (cppfile, str, n)
Append the string @var{str} (whose length is @var{n}) to the output buffer.
Assumes there is enough space available.
@end deffn

The next two functions write a '\0' at the current write position,
but do not adjust CPP_WRITTEN.  This is useful if you want to
pass CPP_OUT_BUFFER to a function that expects a nul-terminated string.

@deffn Macro CPP_NUL_TERMINATE_Q (cppfile)
Same as CPP_RESERVE(@var{cppfile}, 1) followed by
CPP_PWRITTEN(@var{cppfile})='\0'.
@end deffn

@deffn Macro CPP_NUL_TERMINATE_Q (cppfile)
Same as CPP_PWRITTEN(@var{cppfile})='\0'.
Assumes there is space available for the '\0'.
@end deffn

The next two macros are commonly used to truncate the output buffer
or "pop off" text from its end.

@deffn Macro CPP_SET_WRITTEN (cppfile, length)
Set CPP_WRITTEN (@var{cppfile}) to @var{length}.
@end deffn

@deffn Macro CPP_ADJUST_WRITTEN (cppfile, delta)
Adds @var{length} to CPP_WRITTEN (@var{cppfile}).
Usually, @var{length} is negative, but it need not be, as long
as you have reserved enough space.
@end deffn

@bye

Re: prototyping

[H.J. Lu]

> 
>   In message <m0wzo16-0004ecC@ocean.lucon.org>you write:
>   > > 
>   > > 
>   > > > I don't think Kenner will install it.
>   > > 
>   > > I started doing some prototyping a couple years ago and Kenner
>   > > rejected my patches, so I gave up.
>   > 
>   > I will break my huge patch up into small pieces. But it
>   > will take a while. What kind of division is better, by file?
> I think by file -- which is how the intial prototyping work went into
> the compiler -- file by file.
> 
> Maybe a good first step is to get each file's static functions dealt with
> first.
> 
> Then start getting all the missing prototypes for extern functions dealt
> with working on one .h file at a time.

I am thinking the other way around since I have removed those
incomplete external function declarations in .c files, using the
ones in .h files instead. I will first send in patches for .h files,
then .c files.

> 
> The last step would be to start fixing all the target config files.
> 

I have finished Linux/x86.


H.J.

Re: prototyping

[Jeffrey A Law]

  In message <m0wzo16-0004ecC@ocean.lucon.org>you write:
  > > 
  > > 
  > > > I don't think Kenner will install it.
  > > 
  > > I started doing some prototyping a couple years ago and Kenner
  > > rejected my patches, so I gave up.
  > 
  > I will break my huge patch up into small pieces. But it
  > will take a while. What kind of division is better, by file?
I think by file -- which is how the intial prototyping work went into
the compiler -- file by file.

Maybe a good first step is to get each file's static functions dealt with
first.

Then start getting all the missing prototypes for extern functions dealt
with working on one .h file at a time.

The last step would be to start fixing all the target config files.


  > cpplib.c is not used in Linux. I also left out gcc.c and a few
  > other files. I am afraid my current patch is already too big.
  > After it is installed, I will take care of others.
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?


Jeff

Re: prototyping

[Per Bothner]

> cpplib.c is not used in Linux.

The hope is that one day it will replace cccp on all platforms.
My recent USE_CPPLIB patches were one step in this direction.

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

Re: prototyping

[H.J. Lu]

> 
> 
> > I don't think Kenner will install it.
> 
> I started doing some prototyping a couple years ago and Kenner
> rejected my patches, so I gave up.

I will break my huge patch up into small pieces. But it
will take a while. What kind of division is better, by file?

> 
> I noticed the patches don't modify cpplib.c.  Did you forget to check
> it or was it already clean?
> 
> 

cpplib.c is not used in Linux. I also left out gcc.c and a few
other files. I am afraid my current patch is already too big.
After it is installed, I will take care of others.


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

Re: prototyping

[John Carr]

> I don't think Kenner will install it.

I started doing some prototyping a couple years ago and Kenner
rejected my patches, so I gave up.

I noticed the patches don't modify cpplib.c.  Did you forget to check
it or was it already clean?

Re: prototyping

[Jeffrey A Law]

  In message <m0wza2v-0004ecC@ocean.lucon.org>you write:
  > > If not, we'll pick them up as part of a gcc2->egcs merge at some
  > > point.
  > > 
  > 
  > I don't think Kenner will install it.
As Michael pointed out, it's far more likely to get installed by Kenner
if you don't submit it as a monster patch.  That's true for just about
any patch you send to Kenner.

Sending monster patches also makes our job difficult.  While we want the
contribution, sending it in smaller pieces may allow it to go in much
quicker (to both egcs and gcc2).

One key thing to remember is that we do want to open up development and
get changes installed much quicker than has occured with gcc2, but we
don't want to just blindly install huge patches.

Jeff

Re: prototyping

[Jeffrey A Law]

  In message <m0wzZj7-0004ecC@ocean.lucon.org>you write:
  > Hi,
  > 
  > I just sent out 2 big prototyping patches to gcc2 and g++. Should
  > I make one for egcs? I noticed that none of the bugs spotted by
  > my prototype have been fixed in egcs.
Yes.  If you could make it relative to the egcs sources that would
be even better.

If not, we'll pick them up as part of a gcc2->egcs merge at some
point.

jeff

Re: prototyping

[H.J. Lu]

> 
>   In message <m0wzZj7-0004ecC@ocean.lucon.org>you write:
>   > Hi,
>   > 
>   > I just sent out 2 big prototyping patches to gcc2 and g++. Should
>   > I make one for egcs? I noticed that none of the bugs spotted by
>   > my prototype have been fixed in egcs.
> Yes.  If you could make it relative to the egcs sources that would
> be even better.

Will do.

> 
> If not, we'll pick them up as part of a gcc2->egcs merge at some
> point.
> 

I don't think Kenner will install it.

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

prototyping

[H.J. Lu]

Hi,

I just sent out 2 big prototyping patches to gcc2 and g++. Should
I make one for egcs? I noticed that none of the bugs spotted by
my prototype have been fixed in egcs.


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