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

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

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: GCC Projects?

[Jim Wilson]

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

I already happen to have a bytecode-removal patch.

Jim

Monday morning

[Philippe Laliberte]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Hello,

        I have been reading the list and looking at the snapshot over the
weekend, and it seem's clear that I'm a bit lost. Can some one point to me some
reading to do in the hope that I can contribute one day something usefull?

        Utill that day I'll keep reading and trying to play with the snapshot.
Thank's for being their.


---

Bonne journée,
Have a nice day,

  _____________________________________________________________________
|Philippe Laliberte             |        http://www.mlink.net/~arsphl/  |
| ___ Arsphl ___                |        http://oeil.qc.ca/             |
| arsphl@mlink.net              |                                       |
| arsphl@oeil.qc.ca             |        NO SPAM PLEASE                 |
  _____________________________________________________________________

Re: GCC Projects?

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970818102506.302I-100000@hutch.informatik.rwth-aach
en.de>you write:
  > > 
  > > 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?
Not quite yet.

Ripping out the bytecode will make gcc2 -> egcs merging more difficult in
the short term, so unless there's a noteworthy benefit I'd like to avoid
gratutious changes right now.

Looking a little into the future, I see it being ripped out unless someone
objects.

jeff

Re: GCC Projects?

[Jeffrey A Law]

  > As for bytecode generation, there are serious maintenance problems with
  > what has been done so far.
I don't think there's any question the bytecode stuff is horribly
broken and a maintenance nightmare.

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

jeff

Re: GCC Projects?

[Jim Wilson]

	I see that there are two main unfinished projects in the egcs
	source tree: pre-compiled include files and bytecode generation.
	Is anyone working on one of these?

Per Bothner already commented on pre-compiled header files, and I agree
with his comments that we should get cpplib working first, and that the
current implementation of pre-compiled header files does not seem to be
the right approach.

As for bytecode generation, there are serious maintenance problems with
what has been done so far.  The current support was added in between and
along side the tree->RTL conversions.  The result is that there are almost
a hundred different places that have
	if (output_bytecode) { emit bytecodes } else { emit RTL }
The bytecode support was working at one time, but it now badly broken because
this is too difficult to maintain.  I think the implementation needs to be
completely rethought.  In the long term, the best solution might be to
clean up the front-end/middle-end interface.  If the front-end ends convert
an entire function to trees before calling the middle-end, then we only need
one place in the middle-end that checks for whether we are generating bytecodes
or RTL.  This will allow us to separate the bytecode middle-end from the RTL
middle-end, which should make it easier to maintain both of them.

Jim

An autoconf patch

[H.J. Lu]

Hi,

This patch should fix the config.h problem when host != build.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
---
Sun Aug 17 13:41:42 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* Makefile.in ($(srcdir)/config1.in): Changed from
	$(srcdir)/config.in.
	(config1.h): Changed from config.h.
	(cstamp-h.in): Depend on config1.in.
	(native): Depend on config1.h.
	(distclean): Remove config1.h instead of config.h.

	* configure.in (AC_CONFIG_HEADER): Use config1.h:config1.in
	instead of config.h:config.in.
	(--with-config1-h): New argument. Create config1.h.
	(AC_CHECK_HEADERS): Add wait.h sys/wait.h.
	(AC_CHECK_FUNCS): Check strerror.
	(bconfig1.h): Create it if the build machine is not the same
	as the host machine.
	(hconfig.h): Include bconfig1.h if the build machine is not the
	same as the host machine. Otherwise include config1.h.
	(AC_OUTPUT): Use xconfig1.h:config1.in instead of
	xconfig.h:config.in.

	* config.h: New.

	* acconfig.h: Don't include config2.h.

Index: acconfig.h
===================================================================
RCS file: /home/work/cvs/gnu/gcc/acconfig.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 acconfig.h
--- acconfig.h	1997/07/22 01:15:17	1.1.1.1
+++ acconfig.h	1997/08/17 19:59:41
@@ -1,8 +1,3 @@
-
-/* Include the old config.h as config2.h to simplify the transition
-   to autoconf.  */
-#include "config2.h"
-
 /* Whether malloc must be declared even if <stdlib.h> is included.  */
 #undef NEED_DECLARATION_MALLOC
 
Index: configure.in
===================================================================
RCS file: /home/work/cvs/gnu/gcc/configure.in,v
retrieving revision 1.13
diff -u -r1.13 configure.in
--- configure.in	1997/08/03 20:11:26	1.13
+++ configure.in	1997/08/17 20:15:24
@@ -22,7 +22,7 @@
 
 # Initialization and defaults
 AC_INIT(tree.c)
-AC_CONFIG_HEADER(config.h:config.in)
+AC_CONFIG_HEADER(config1.h:config1.in)
 
 native_prefix=/usr
 remove=rm
@@ -32,6 +32,12 @@
 
 # Check for additional parameters
 
+# Generate config1.h only.
+AC_ARG_WITH(config1-h,
+[  --with-config1-h        generate config1.h only.],
+config1_h_only=yes,
+config1_h_only=no)
+
 # With GNU ld
 AC_ARG_WITH(gnu-ld,
 [  --with-gnu-ld           arrange to work with GNU ld.],
@@ -133,7 +139,10 @@
 AC_PROG_CC
 AC_PROG_MAKE_SET
 
-AC_CHECK_HEADERS(stddef.h string.h strings.h stdlib.h time.h unistd.h)
+AC_CHECK_HEADERS(stddef.h string.h strings.h stdlib.h time.h unistd.h \
+	wait.h sys/wait.h)
+
+AC_CHECK_FUNCS(strerror)
 
 GCC_NEED_DECLARATION(malloc)
 GCC_NEED_DECLARATION(realloc)
@@ -2766,6 +2775,20 @@
 	done
 done
 
+if [[ -f hconfig.h ]]
+then
+  rm -f hconfig.h.tmp
+  if [[ x$build != x$host ]]
+  then
+    echo "#include \"bconfig1.h\"" > hconfig.h.tmp  
+  else
+    echo "#include \"config1.h\"" > hconfig.h.tmp  
+  fi
+  cat hconfig.h >> hconfig.h.tmp
+  rm -f hconfig.h
+  mv hconfig.h.tmp hconfig.h
+fi
+
 # Truncate the target if necessary
 if [[ x$host_truncate_target != x ]]; then
 	target=`echo $target | sed -e 's/\(..............\).*/\1/'`
@@ -3143,7 +3166,7 @@
 [
 . $srcdir/configure.lang
 case x$CONFIG_HEADERS in
-xconfig.h:config.in)
+xconfig1.h:config1.in)
 echo > cstamp-h ;;
 esac
 ],
@@ -3177,3 +3200,22 @@
 cross_overrides='${cross_overrides}'
 build_overrides='${build_overrides}'
 ])
+
+# We need to create config1.h for the build machine if it is not the
+# same as host.
+if [[ $config1_h_only != yes -a x$build != x$host ]]
+then
+	tempdir=build.$$
+	rm -rf $tempdir
+	mkdir $tempdir
+	cd $tempdir
+	case ${srcdir} in
+	/*) realsrcdir=${srcdir};;
+	*) realsrcdir=../${srcdir};;
+	esac
+	CC=${BUILD_CC-cc} ${realsrcdir}/configure --with-config1-h \
+		--target=$target --host=$host --build=$build
+	mv config1.h ../bconfig1.h
+	cd ..
+	rm -rf $tempdir
+fi
Index: Makefile.in
===================================================================
RCS file: /home/work/cvs/gnu/gcc/Makefile.in,v
retrieving revision 1.47
diff -u -r1.47 Makefile.in
--- Makefile.in	1997/08/03 20:11:23	1.47
+++ Makefile.in	1997/08/17 19:28:20
@@ -665,7 +665,7 @@
 $(srcdir)/configure: $(srcdir)/configure.in
 	cd $(srcdir); autoconf
 
-# cstamp-h.in controls rebuilding of config.in.
+# cstamp-h.in controls rebuilding of config1.in.
 # It is named cstamp-h.in and not stamp-h.in so the mostlyclean rule doesn't
 # delete it.  A stamp file is needed as autoheader won't update the file if
 # nothing has changed.
@@ -674,13 +674,13 @@
 # "echo timestamp" is used instead of touch to be consistent with other
 # packages that use autoconf (??? perhaps also to avoid problems with patch?).
 # ??? Newer versions have a maintainer mode that may be useful here.
-$(srcdir)/config.in: $(srcdir)/cstamp-h.in
+$(srcdir)/config1.in: $(srcdir)/cstamp-h.in
 $(srcdir)/cstamp-h.in: $(srcdir)/configure.in $(srcdir)/acconfig.h
 	cd $(srcdir) && autoheader
 	echo timestamp > $(srcdir)/cstamp-h.in
-config.h: cstamp-h ; @true
-cstamp-h: config.in config.status
-	CONFIG_HEADERS=config.h:config.in $(SHELL) config.status
+config1.h: cstamp-h ; @true
+cstamp-h: config1.in config.status
+	CONFIG_HEADERS=config1.h:config1.in $(SHELL) config.status
 
 # Really, really stupid make features, such as SUN's KEEP_STATE, may force
 # a target to build even if it is up-to-date.  So we must verify that
@@ -707,7 +707,7 @@
 rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) lang.rest.encap
 # This is what is made with the host's compiler
 # whether making a cross compiler or not.
-native: config.status config.h cpp $(LANGUAGES) \
+native: config.status config1.h cpp $(LANGUAGES) \
 	$(EXTRA_PASSES) $(EXTRA_PROGRAMS) $(USE_COLLECT2)
 
 # Define the names for selecting languages in LANGUAGES.
@@ -2052,7 +2052,7 @@
 # Delete all files that users would normally create
 # while building and installing GCC.
 distclean: clean bytecode.distclean lang.distclean
-	-rm -f tm.h config.h config2.h tconfig.h hconfig.h md cstamp-h
+	-rm -f tm.h config1.h config2.h tconfig.h hconfig.h md cstamp-h
 	-rm -f config.status config.run config.cache config.bak
 	-rm -f Make-lang Make-hooks Make-host Make-target
 	-rm -f Makefile specs.h options.h *.oaux
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ config.h	Wed Aug  6 15:07:47 1997
@@ -0,0 +1,2 @@
+#include "config1.h"
+#include "config2.h"

Re: GCC Projects?

[Joel Sherrill]

On Sun, 17 Aug 1997, Jeffrey A Law wrote:

>   > I see that there are two main unfinished projects in the egcs
>   > source tree: pre-compiled include files and bytecode generation.
>   > Is anyone working on one of these?
> Nobody is working on these as far as I know.  Lots of other stuff
> is probably more important -- cpplib, lots of optimization work,
> fold in ada & pascal front ends, packaging & release issues, docs,
> etc etc.

I would like to put a plug in for architectural simulators here.  There
are a number of targets --especially embedded ones -- which are difficult
and/or time-consuming to test.  Of the RTEMS configurations (about 8
different ones), I can only do automated tests on 2 of them (powerpc and
sparc).  The others I can only verify that they can successfully build a
full toolchain and support libraries.  Periodically, I run code on actual
target boards.  

Long term, if the testing of egcs (and other support libraries) is to be
full and complete, we really need to find/develop good simulators for a
handful of cpus. 

--joel
Joel Sherrill                    Sr. Computer Scientist
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

egcs-ss-970814 on m68k-next-nextstep3

[Toon Moene]

Results for `make bootstrap CFLAGS="-g -O3 -fno-regmove" LANGUAGES=c'.

A regression with respect to the not-so-public egcs-ss-970813:

- I had to compile config/nextstep.c by hand.

- Furthermore, convert.c is compiled twice.

Both are shortcomings I noted with a recent gcc snapshot too.

The hang at enquire:

Apparently, it happens in routine F_check, because the last routine  
in enquire.s is:

.globl _fSelf
_fSelf:

When stopped with Control-C, I get:

Reading in symbols for real.c...done.
etoasc (x=0x6, string=0x3fff4f6 "", ndigs=20) at real.c:1887
1887          bits <<= 1;
(gdb) bt
Reading in symbols for config/m68k/m68k.c...done.
Reading in symbols for final.c...done.
Reading in symbols for toplev.c...done.
Reading in symbols for c-decl.c...done.
Reading in symbols for c-parse.c...done.
#0  etoasc (x=0x6, string=0x3fff4f6 "", ndigs=20) at real.c:1887
#1  0x74c2a in ereal_to_decimal (x=void, s=0x3fff4f6 "") at real.c:1210
#2  0xec338 in print_operand (file=0x3fff4f6, op=0x443214,  
letter=67106038) at config/m68k/m68k.c:2734
#3  0xcee26 in output_operand (x=0x443214, code=102) at final.c:2713
#4  0xceb00 in output_asm_insn (template=0x3fff452 "",  
operands=0x1356e0) at final.c:2637
#5  0xce3d4 in final_scan_insn (insn=0x443244, file=0x1,  
optimize=0, prescan=110, nopeepholes=0) at final.c:2168
#6  0xcd5d8 in final (first=0x1356e0, file=0x1, optimize=110,  
prescan=0) at final.c:1322
#7  0x226cc in rest_of_compilation (decl=void) at toplev.c:3592
#8  0xfc46 in finish_function (nested=0) at c-decl.c:7012
#9  0x2d44 in yyparse () at c-parse.y:352
#10 0x1f2c4 in compile_file (name=0x3fffcde "enquire.i") at toplev.c:2470
#11 0x233c2 in main (argc=12, argv=0x124d2c, envp=0x3fffc88) at  
toplev.c:4309

but

(gdb) whatis x
type = unsigned short *

the value 0x6 seems a bit odd for a pointer.

HTH,
Toon.

Re: GCC Projects?

[Jeffrey A Law]

  In message <k2hgcovl4a.fsf@zero.aec.at>you write:
  > Hi,
  > 
  > I see that there are two main unfinished projects in the egcs
  > source tree: pre-compiled include files and bytecode generation.
  > Is anyone working on one of these?
Nobody is working on these as far as I know.  Lots of other stuff
is probably more important -- cpplib, lots of optimization work,
fold in ada & pascal front ends, packaging & release issues, docs,
etc etc.

jeff

Re: GCC Projects?

[Per Bothner]

> I see that there are two main unfinished projects in the egcs
> source tree: pre-compiled include files and bytecode generation.
> Is anyone working on one of these?

As the author of cpplib, I would rather we first finish cpplib
as the default cpp (see my previous message), before we even start
on pre-compiled header files.  RMS has a model for pre-compiled header
files which would not mesh as well with cpplib, and it is unclear
how much of a win it would be anyway.

Bytecode generation is another of RMS's pet projects that no-one
has shown much interst in in years, and it is arguable how useful
it is.  (For one: it does not support C++.)

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

970814 and libg++

[H.J. Lu]

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

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

GCC Projects?

[Andi Kleen]

Hi,

I see that there are two main unfinished projects in the egcs
source tree: pre-compiled include files and bytecode generation.
Is anyone working on one of these?

-Andi