public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* 2 (small?) problems
@ 1997-08-18  8:22 Thomas Hiller
  1997-08-18  9:11 ` Will egcs support MachTen? N8TM
                   ` (4 more replies)
  0 siblings, 5 replies; 23+ messages in thread
From: Thomas Hiller @ 1997-08-18  8:22 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-18 18:22 Per Bothner
  0 siblings, 0 replies; 23+ messages in thread
From: Per Bothner @ 1997-08-18 18:22 UTC (permalink / raw)
  To: egcs

  > 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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 15:11 meissner
  1997-08-18 15:36 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: meissner @ 1997-08-18 15:11 UTC (permalink / raw)
  To: egcs

|   In message <9708181258.AA19853@moene.indiv.nluug.nl>you write:
|   > Isn't this something that would have been solved [ coniunctivus  
|   > irrealis ! ] by live range splitting ?
| Not entirely.  live range splitting should significantly reduce
| the number of spills, but it won't always be able to completely
| eliminate them (in theory it can completely eliminate them, but
| in practice it doesn't).  Thus you still need to deal with spilling
| registers.

Yes, I think it is obvious that you will always need to spill registers.  Also,
live range splitting as I'm currently implementing it will still be generating
spills.  I do think the previous posting on register spills is also helpful and
plan to look at it when I get in the office (I didn't mention to disparage it,
my first posting was made pre-coffee).  My comment on reload is meant for more
reload as we currently know it.  I think it is an horrible kludge that reload
is run as a pass after global-alloc, and that it forces reload registers not to
be used for any other purpose (which is murder on the x86 with each register
being special purpose in some way).  I think it should be integrated into
global-alloc, taking lifetimes, ranges, etc. into consideration, possibly
leaving the fossil reload for when you are not optimizing.  Given that reload
has pretty much been the place where we all fear to tread, at least since RMS
handed over the gcc2 reigns to Kenner (and even in the 1.3x time frame, I got
the sense that RMS no longer had a good handle on reload anymore), I think it
is time for a rethought.  Now, given it is a rather critical piece of the
compiler, it may take months if not years to get it better than it currently
is.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-17 21:55 H.J. Lu
  1997-08-17 22:18 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: H.J. Lu @ 1997-08-17 21:55 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-17 21:48 H.J. Lu
  1997-08-17 21:48 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: H.J. Lu @ 1997-08-17 21:48 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: 970814 and libg++
@ 1997-08-17 18:01 Mumit Khan
  1997-08-17 19:06 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: Mumit Khan @ 1997-08-17 18:01 UTC (permalink / raw)
  To: egcs

hjl@lucon.org (H.J. Lu) writes:
> > 
> > btw, static template data members are not being instantiated breaking SGI
> > STL in libg++-2.8.0b6 (the allocator in particular). Also, I'm getting a 
> > core dump when compiling libstdc++ tests when compiling with '-g -O2', but 
> > with -g. Anybody else seen this? This is on a hppa1.1-hp-hpux10.20 using 
> > GAS from binutils 2.8.1. I'll investigate this further on other platforms.
> > 
> 
> Same here on Linux/x86.

Just tried i386-linux-gnulibc1 and static template data *is* being
instantiated! The core dump however remains whenever -O is used for
libstdc++/test/tmap.cc.

gdb output:

===========

[khan@home] gdb tmap core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
Core was generated by `./tmap'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from
/homes/src/libg++-2.8.0/libstdc++/../libstdc++/libstdc++.so.2.8...done.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/libm.so.5.0.6...done.
Reading symbols from /lib/ld-linux.so.1...done.
#0  0x804990b in rb_tree<int, pair<int const, int>, select1st<pair<int
const, int> >, int_less, __default_alloc_template<false, 0>
>::insert_unique (
    this=0xbffff3b8, v=@0xbffff358) at ../stl/tree.h:125
125             y = y->right;
(gdb) where
#0  0x804990b in rb_tree<int, pair<int const, int>, select1st<pair<int
const, int> >, int_less, __default_alloc_template<false, 0>
>::insert_unique (
    this=0xbffff3b8, v=@0xbffff358) at ../stl/tree.h:125
#1  0x8048f13 in main (argv=1, argc=0xbffff3e4) at ../stl/map.h:110
#2  0x804885b in ___crt_dummy__ ()
(gdb) print y
$1 = (__rb_tree_node_base *) 0x414c4658
(gdb) print *y
Cannot access memory at address 0x414c4658.

===========

Mumit

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-17 17:52 Per Bothner
  0 siblings, 0 replies; 23+ messages in thread
From: Per Bothner @ 1997-08-17 17:52 UTC (permalink / raw)
  To: egcs

> 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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-17 14:30 H.J. Lu
  0 siblings, 0 replies; 23+ messages in thread
From: H.J. Lu @ 1997-08-17 14:30 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* egcs-ss-970814
@ 1997-08-16 23:30 David S. Miller
  1997-08-17 14:30 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: David S. Miller @ 1997-08-16 23:30 UTC (permalink / raw)
  To: egcs

Bootstrapped successfully and passed make compare (except of course
for the zzz.o file) on sparc-linux-gnulibc1 both with and without the
Haifa scheduler enabled.

Any timeframe on a initial cut of the new test suite mechanism?  I'd
like to start cranking.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-16 19:16 Per Bothner
  0 siblings, 0 replies; 23+ messages in thread
From: Per Bothner @ 1997-08-16 19:16 UTC (permalink / raw)
  To: egcs

> 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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-16 17:50 H.J. Lu
  0 siblings, 0 replies; 23+ messages in thread
From: H.J. Lu @ 1997-08-16 17:50 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-16 14:00 John Carr
  0 siblings, 0 replies; 23+ messages in thread
From: John Carr @ 1997-08-16 14:00 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: two ftp mirrors of egcs are up
@ 1997-08-16  5:24 Ryuichiro ARAKI
  1997-08-16  5:37 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: Ryuichiro ARAKI @ 1997-08-16  5:24 UTC (permalink / raw)
  To: egcs

>>>>> On Sat, 16 Aug 1997 13:51:01 +0900 Jason Molenda wrote:
> > ftp://ftp.pmi.saitama-med.ac.jp/pcg/ will also have mirrors of those
> > files, since it mirrors Marc's ftp.goof.com.
> 
> 
> Cool.  As pentinenace, I will avoid refering to Saitama as Dasaitama for
> a day. :-) :-)

Oops, for those who are not familiar with Japanese language, I'll comment
on the word "Dasaitama."

"Dasai" in Japanese never means "countrified", but "cool", "neat", or
something like that ;-) ;-) ;-)

Dr. Ryuichiro ARAKI
Preventive Medical Institution (PMI)  _/_/_/_/_/    _/_/   _/_/    _/_/_/_/_/
Dept. of Hyg. & Preventive Medicine  _/            _/  _/_/ _/    _/
SAITAMA MEDICAL SCHOOL              _/_/_/_/_/    _/   _/  _/    _/_/_/_/_/
Phone : +81-492-76-1168                    _/    _/       _/            _/
Fax   : +81-492-94-6907           _/_/_/_/_/    _/       _/    _/_/_/_/_/
e-mail: raraki@saitama-med.ac.jp

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: prototyping
@ 1997-08-16  3:51 H.J. Lu
  0 siblings, 0 replies; 23+ messages in thread
From: H.J. Lu @ 1997-08-16  3:51 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* prototyping
@ 1997-08-16  3:18 H.J. Lu
  1997-08-16  3:51 ` prototyping Jeffrey A Law
  0 siblings, 1 reply; 23+ messages in thread
From: H.J. Lu @ 1997-08-16  3:18 UTC (permalink / raw)
  To: egcs

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)

^ permalink raw reply	[flat|nested] 23+ messages in thread
end of thread, other threads:[~1997-08-18 18:22 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-18  8:22 2 (small?) problems Thomas Hiller
1997-08-18  9:11 ` Will egcs support MachTen? N8TM
1997-08-18  9:11 ` prototyping Andi Kleen
1997-08-18  9:11 ` GCC Projects? Bernd Schmidt
1997-08-18 10:42 ` front end interface Clive Nicolson
1997-08-18 13:29 ` [EGCS] Re: double alignment patch for x86 Dave Love
  -- strict thread matches above, loose matches on Subject: below --
1997-08-18 18:22 prototyping Per Bothner
1997-08-18 15:11 Reload patch to improve 386 code meissner
1997-08-18 15:36 ` prototyping Jeffrey A Law
1997-08-17 21:55 prototyping H.J. Lu
1997-08-17 22:18 ` prototyping Jeffrey A Law
1997-08-17 21:48 prototyping H.J. Lu
1997-08-17 21:48 ` prototyping Jeffrey A Law
1997-08-17 18:01 970814 and libg++ Mumit Khan
1997-08-17 19:06 ` prototyping Jeffrey A Law
1997-08-17 17:52 prototyping Per Bothner
1997-08-17 14:30 prototyping H.J. Lu
1997-08-16 23:30 egcs-ss-970814 David S. Miller
1997-08-17 14:30 ` prototyping Jeffrey A Law
1997-08-16 19:16 prototyping Per Bothner
1997-08-16 17:50 prototyping H.J. Lu
1997-08-16 14:00 prototyping John Carr
1997-08-16  5:24 two ftp mirrors of egcs are up Ryuichiro ARAKI
1997-08-16  5:37 ` prototyping Jeffrey A Law
1997-08-16  3:51 prototyping H.J. Lu
1997-08-16  3:18 prototyping H.J. Lu
1997-08-16  3:51 ` prototyping Jeffrey A Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).