public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-22 19:23 Jeffrey A Law
  1997-08-22 19:23 ` Questions about Haifa scheduler Jeffrey A Law
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Jeffrey A Law @ 1997-08-22 19:23 UTC (permalink / raw)
  To: egcs

  > The hang at enquire:
  > 
  > Apparently, it happens in routine F_check, because the last routine  
  > in enquire.s is:
Can you send me the cpp output for enquire on your box so I can
look at things under the debugger?

jeff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fixing the c++/f77 circular dependency
  1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
  1997-08-22 19:23 ` Questions about Haifa scheduler Jeffrey A Law
@ 1997-08-22 19:23 ` Jim Wilson
  1997-08-22 19:38 ` patches for libg++ Alexandre Oliva
  1997-08-22 19:47 ` libstdc++ and gcc2 merge Jason Merrill
  3 siblings, 0 replies; 9+ messages in thread
From: Jim Wilson @ 1997-08-22 19:23 UTC (permalink / raw)
  To: egcs

	But LANGUAGES is still desirable for bootstrapping, because if you compile
	with an inferior system compiler you only want to build the C compiler
	with it, and them build the rest with the just built gcc.

We do need a way to build only the C compiler in the first stage of a
bootstrap.  However, we do not have any particular need for LANGUAGES itself.
If we can find some other way to build only the C compiler, then we can get
rid of LANGUAGES.  For instance, it might be possible to have a `make all'
target that builds all languages, and a `make only_c' target that builds
only the C language stuff.

Jim

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Questions about Haifa scheduler
  1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
@ 1997-08-22 19:23 ` Jeffrey A Law
  1997-08-22 19:23 ` fixing the c++/f77 circular dependency Jim Wilson
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 9+ messages in thread
From: Jeffrey A Law @ 1997-08-22 19:23 UTC (permalink / raw)
  To: egcs

  In message <19970822131918.44330@puma.macbsd.com>you write:
  > > Are you just looking for performance information?  Or are you looking
  > > for technical information?  Regardless, this is the place to ask.
  > 
  > More for technical information--it's probably too early to get any
  > meaningful performance comparison (except possibly on the PPC model(s)
  > that the development team was working with).
OK.  I (and others) posted some general information about it to the
list -- you can probably find them in the list archives on
http://www.cygnus.com/egcs .

  > Heh...  That's a little surprising since it's been around for a while
  > and I thought a lot of folks were using gcc for 68k-based embedded
  > systems...
Well, first the machine has to be able to have multiple instructions
running at the same time.  For older 68ks this was probably only
possible with FP insns.  Newer ports may be different.

Second, someone actually was to describe the machine to the scheduler;
and with the way the 68k port has been written describing it to the
scheduler would be a non-trivial project.

Jeff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* patches for libg++
  1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
  1997-08-22 19:23 ` Questions about Haifa scheduler Jeffrey A Law
  1997-08-22 19:23 ` fixing the c++/f77 circular dependency Jim Wilson
@ 1997-08-22 19:38 ` Alexandre Oliva
  1997-08-22 19:47 ` libstdc++ and gcc2 merge Jason Merrill
  3 siblings, 0 replies; 9+ messages in thread
From: Alexandre Oliva @ 1997-08-22 19:38 UTC (permalink / raw)
  To: egcs

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: text/plain; charset=US-ASCII

Here are some patches for libg++ that I currently have applied to my
libg++-2.8.0b6 tree.  They do not conflict with Lu's.

The first one may seem unnecessary, but when I applied it I used to
test gcc/g++/libg++ on an AIX host and it would only build a shared
libg++ after this patch.  I don't know whether it was a bug in
gcc/collect2, GNU ld or AIX's ld or whatever, and I no longer have
access to any AIX host.

The second set of patches is necessary for creating correct soft links
for shared libg++ and libstdc++ at install time.

The third set of patches embeds the full pathname into shared
libraries, so that the fact that they are shared is transparent for
users (they do not have to issue -R/usr/local/lib nor set
LD_LIBRARY_PATH in order to run programs linked against them)

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="patch1.diff"
Content-Transfer-Encoding: 7bit

	* libg++/config/aix.ml: change shared library dependencies

diff -ru libg++-2.8.0/libg++/config/aix.ml libg++-2.8.0/libg++/config/aix.ml
--- libg++-2.8.0/libg++/config/aix.ml	Fri Feb 14 07:37:06 1997
+++ libg++-2.8.0/libg++/config/aix.ml	Mon Mar 24 15:36:06 1997
@@ -3,5 +3,5 @@
 ARLIB	   = libg++-ar.a
 SHLINK     = libg++.a
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHDEPS     = ../libstdc++/libstdc++.a -lm
+SHDEPS     = -L../libstdc++ -lstdc++ -lm
 SHFLAGS  = -Wl,-unix

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="patch2.diff"
Content-Transfer-Encoding: 7bit

	* libg++/Makefile.in: correctly handle multiple links to
	shared libraries
	* libstdc++/Makefile.in: ditto

diff -ru libg++-2.8.0/libg++/Makefile.in libg++-2.8.0/libg++/Makefile.in
--- libg++-2.8.0/libg++/Makefile.in	Fri Feb 14 07:44:06 1997
+++ libg++-2.8.0/libg++/Makefile.in	Fri Aug 22 15:55:56 1997
@@ -192,8 +192,13 @@
 	rootme=`pwd`/ ; export rootme ; \
 	for FILE in $(BUILD_LIBS) ; do \
 	  rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
-	  if [ $$FILE = $(SHLINK) ] || [ $$FILE = $(MSHLINK) ]; then \
+	  if [ $$FILE = $(SHLINK) ] ; then \
 	    ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	  elif [ $$FILE = mshlink ]; then \
+	    for FILE in $(MSHLINK) ; do \
+	      rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	      ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	    done; \
 	  elif [ $$FILE = $(SHLIB) ]; then \
 	    $(INSTALL_PROGRAM) $$FILE $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
 	    : On the HP, shared libraries must be mode 555. ;\
diff -ru libg++-2.8.0/libstdc++/Makefile.in libg++-2.8.0/libstdc++/Makefile.in
--- libg++-2.8.0/libstdc++/Makefile.in	Fri Feb 14 07:39:39 1997
+++ libg++-2.8.0/libstdc++/Makefile.in	Fri Aug 22 15:56:05 1997
@@ -263,8 +263,13 @@
 	rootme=`pwd`/ ; export rootme ; \
 	for FILE in $(LIBS) ; do \
 	  rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
-	  if [ $$FILE = $(SHLINK) ] || [ $$FILE = $(MSHLINK) ]; then \
+	  if [ $$FILE = $(SHLINK) ] ; then \
 	    ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	  elif [ $$FILE = mshlink ]; then \
+	    for FILE in $(MSHLINK) ; do \
+	      rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	      ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	    done; \
 	  elif [ $$FILE = $(SHLIB) ]; then \
 	    $(INSTALL_PROGRAM) $$FILE $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
 	    : On the HP, shared libraries must be mode 555. ;\

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="patch3.diff"
Content-Transfer-Encoding: 7bit

	* libg++/Makefile.in: put full installation pathname in shared
	library, so that their existence is transparent to users.
	* libg++/config/elf.ml: ditto
	* libg++/config/elfshlibm.ml: ditto
	* libg++/config/linux.ml: ditto
	* libg++/config/sol2shm.ml: ditto
	* libstdc++/Makefile.in: ditto
	* libstdc++/config/elf.ml: ditto
	* libstdc++/config/elfshlibm.ml: ditto
	* libstdc++/config/linux.ml: ditto
	* libstdc++/config/sol2shm.ml: ditto

diff -ru libg++-2.8.0/libg++/Makefile.in libg++-2.8.0/libg++/Makefile.in
--- libg++-2.8.0/libg++/Makefile.in	Fri Feb 14 07:44:06 1997
+++ libg++-2.8.0/libg++/Makefile.in	Fri Aug 22 15:55:56 1997
@@ -71,7 +71,7 @@
 SHARLIB = libg++-sh.a
 SHLINK  = libg++.so
 MSHLINK = libg++.so.`echo $(VERSION) | sed 's/\([0-9][.][0-9]\).*/\1/'`
-SHFLAGS =
+SHFLAGS = -Wl,-soname,$(libdir)/$(SHLIB)
 SHDEPS  = -L../libstdc++ -lstdc++ -lm
 
 BUILD_LIBS = $(ARLIB)
diff -ru libg++-2.8.0/libg++/config/elf.ml libg++-2.8.0/libg++/config/elf.ml
--- libg++-2.8.0/libg++/config/elf.ml	Fri Feb 14 07:37:06 1997
+++ libg++-2.8.0/libg++/config/elf.ml	Mon Mar 24 15:36:06 1997
@@ -1,3 +1,3 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS    = -h $(SHLIB)
+SHFLAGS    = -h $(libdir)/$(SHLIB)
 LIBS       = -L./$(TOLIBGXX) -L./$(TOLIBGXX)../libstdc++ -lg++ -lstdc++ -lm
diff -ru libg++-2.8.0/libg++/config/elfshlibm.ml libg++-2.8.0/libg++/config/elfshlibm.ml
--- libg++-2.8.0/libg++/config/elfshlibm.ml	Fri Feb 14 07:37:06 1997
+++ libg++-2.8.0/libg++/config/elfshlibm.ml	Mon Mar 24 15:36:06 1997
@@ -1,3 +1,3 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS    = -h $(SHLIB)
+SHFLAGS    = -h $(libdir)/$(SHLIB)
 SHDEPS     = -lm
diff -ru libg++-2.8.0/libg++/config/linux.ml libg++-2.8.0/libg++/config/linux.ml
--- libg++-2.8.0/libg++/config/linux.ml	Fri Feb 14 07:37:07 1997
+++ libg++-2.8.0/libg++/config/linux.ml	Mon Mar 24 15:36:07 1997
@@ -1,2 +1,2 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK) mshlink
-SHFLAGS    = -Wl,-soname,$(MSHLINK)
+SHFLAGS    = -Wl,-soname,$(libdir)/$(MSHLINK)
diff -ru libg++-2.8.0/libg++/config/sol2shm.ml libg++-2.8.0/libg++/config/sol2shm.ml
--- libg++-2.8.0/libg++/config/sol2shm.ml	Fri Feb 14 07:37:07 1997
+++ libg++-2.8.0/libg++/config/sol2shm.ml	Mon Mar 24 15:36:07 1997
@@ -1,3 +1,3 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS    = -h $(SHLIB)
+SHFLAGS    = -h $(libdir)/$(SHLIB)
 SHDEPS     = -lm
diff -ru libg++-2.8.0/libstdc++/Makefile.in libg++-2.8.0/libstdc++/Makefile.in
--- libg++-2.8.0/libstdc++/Makefile.in	Fri Feb 14 07:39:39 1997
+++ libg++-2.8.0/libstdc++/Makefile.in	Fri Aug 22 15:56:05 1997
@@ -31,7 +31,7 @@
 SHARLIB = libstdc++-sh.a
 SHLINK  = libstdc++.so
 MSHLINK = libstdc++.so.`echo $(VERSION) | sed 's/\([0-9][.][0-9]\).*/\1/'`
-SHFLAGS = 
+SHFLAGS = -Wl,-soname,$(libdir)/$(SHLIB)
 SHDEPS  =
 
 STAMP   = bigstmp
diff -ru libg++-2.8.0/libstdc++/config/elf.ml libg++-2.8.0/libstdc++/config/elf.ml
--- libg++-2.8.0/libstdc++/config/elf.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/elf.ml	Mon Mar 24 15:36:08 1997
@@ -2,7 +2,7 @@
 # for programs that don't use complex.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS = -h $(SHLIB)
+SHFLAGS = -h $(libdir)/$(SHLIB)
 DEPLIBS = ../$(SHLIB)
 LDLIBS  = -L.. -lstdc++ -lm
 MLDLIBS = -L.. -lstdc++ -lm
diff -ru libg++-2.8.0/libstdc++/config/elfshlibm.ml libg++-2.8.0/libstdc++/config/elfshlibm.ml
--- libg++-2.8.0/libstdc++/config/elfshlibm.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/elfshlibm.ml	Mon Mar 24 15:36:09 1997
@@ -1,6 +1,6 @@
 # Elf with shared libm, so we can link it into the shared libstdc++.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS = -h $(SHLIB)
+SHFLAGS = -h $(libdir)/$(SHLIB)
 SHDEPS  = -lm
 DEPLIBS = ../$(SHLIB)
diff -ru libg++-2.8.0/libstdc++/config/linux.ml libg++-2.8.0/libstdc++/config/linux.ml
--- libg++-2.8.0/libstdc++/config/linux.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/linux.ml	Mon Mar 24 15:36:10 1997
@@ -1,6 +1,6 @@
 # Elf with shared libm, so we can link it into the shared libstdc++.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK) mshlink
-SHFLAGS = -Wl,-soname,$(MSHLINK)
+SHFLAGS = -Wl,-soname,$(libdir)/$(MSHLINK)
 SHDEPS  = -lm
 DEPLIBS = ../$(SHLIB)
diff -ru libg++-2.8.0/libstdc++/config/sol2shm.ml libg++-2.8.0/libstdc++/config/sol2shm.ml
--- libg++-2.8.0/libstdc++/config/sol2shm.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/sol2shm.ml	Mon Mar 24 15:36:10 1997
@@ -1,6 +1,6 @@
 # Solaris2 with shared libm, so we can link it into the shared libstdc++.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS = -h $(SHLIB)
+SHFLAGS = -h $(libdir)/$(SHLIB)
 SHDEPS  = -lm
 DEPLIBS = ../$(SHLIB)

--Multipart_Fri_Aug_22_16:38:40_1997-1--

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: libstdc++ and gcc2 merge
  1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
                   ` (2 preceding siblings ...)
  1997-08-22 19:38 ` patches for libg++ Alexandre Oliva
@ 1997-08-22 19:47 ` Jason Merrill
  3 siblings, 0 replies; 9+ messages in thread
From: Jason Merrill @ 1997-08-22 19:47 UTC (permalink / raw)
  To: egcs

>>>>> H J Lu <hjl@lucon.org> writes:

>> Just a note that snapshots after tonight's will include libstdc++, so you
>> won't have to worry about finding the right version (and I won't have to
>> worry about making my own libg++ releases).

> I didn't see libstdc++ in egcs-ss-970814-970821.diff.gz. Did I miss
> something?

*after* tonight's.

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-23 14:31 Toon Moene
  0 siblings, 0 replies; 9+ messages in thread
From: Toon Moene @ 1997-08-23 14:31 UTC (permalink / raw)
  To: egcs

[ BTW, I'm using egcs-ss-970821 now, which had the same symptoms ]

>  	- I had to compile config/nextstep.c by hand.
>  	- Furthermore, convert.c is compiled twice.

Jim correctly diagnosed this as a problem in one of NEXT's make,  
sed or other utilities (I haven't looked at which one, because I  
normally use a simple alias to switch from standard utilities to GNU  
ones all at once).

After the switch, both problems disappeared (this of course means  
that these snapshots do not build "out of the box" without manual  
intervention on NEXTSTEP, but oh well ...)

Furthermore:

>>	...the stage2 cc1 hangs while compiling enquire...

>  I tracked this down to a bug in the new aliasing code.
>
>  I don't have access to any m68k workstation, so I am
>  unable to test this with a bootstrap.  I found this by
>  inspection of the m68k code generated by the stage1
>  compiler for the real.c function etoasc.  The infinite
>  loop I found there goes away when this patch is applied.

[ And have us, mere mortals, watch in awe ... ]

Yes, This Works (the bootstrap is not finished yet - takes another  
hour - but it passed compiling enquire using the stage2 compiler).

The really irritating thing here, of course, is that I have looked  
at this code and haven't noticed this bug; so much for the Quality  
Control Department at "Moene Computational Physics" :-(

Craig, this bug is also present in f/gbe/2.7.2.2.diff of  
g77-0.5.21-970811.

Cheers,
Toon.

"A truly outstanding programmer can find bugs buried in a 6  
megabyte core dump without using a hex calculator."

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-23  4:37 Jim Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Jim Wilson @ 1997-08-23  4:37 UTC (permalink / raw)
  To: egcs

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

	...the stage2 cc1 hangs while compiling enquire...

I tracked this down to a bug in the new aliasing code.

I don't have access to any m68k workstation, so I am unable to test this
with a bootstrap.  I found this by inspection of the m68k code generated
by the stage1 compiler for the real.c function etoasc.  The infinite loop
I found there goes away when this patch is applied.

Fri Aug 22 21:31:54 1997  Jim Wilson  <wilson@cygnus.com>

	* alias.c (true_dependence): Pass x_addr not x to varies.

Index: alias.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/alias.c,v
retrieving revision 1.3
diff -p -r1.3 alias.c
*** alias.c	1997/08/22 06:39:29	1.3
--- alias.c	1997/08/23 04:31:19
*************** true_dependence (mem, mem_mode, x, varie
*** 825,831 ****
       If either memory reference is a variable structure the other is a
       fixed scalar and there is no aliasing.  */
    if ((MEM_IN_STRUCT_P (mem) && varies (mem_addr))
!       || (MEM_IN_STRUCT_P (x) && varies (x)))
      return 0;
  
    return 1;
--- 825,831 ----
       If either memory reference is a variable structure the other is a
       fixed scalar and there is no aliasing.  */
    if ((MEM_IN_STRUCT_P (mem) && varies (mem_addr))
!       || (MEM_IN_STRUCT_P (x) && varies (x_addr)))
      return 0;
  
    return 1;

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-22 19:47 Toon Moene
  0 siblings, 0 replies; 9+ messages in thread
From: Toon Moene @ 1997-08-22 19:47 UTC (permalink / raw)
  To: egcs

Hi Jeff,

Sent to you in a separate message.  Sorry that I wasn't able to  
debug this myself, but I am not really that good at debugging  
recursive programs like gcc.

Cheers,
Toon.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-17 19:06 Toon Moene
  0 siblings, 0 replies; 9+ messages in thread
From: Toon Moene @ 1997-08-17 19:06 UTC (permalink / raw)
  To: egcs

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~1997-08-23 14:31 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
1997-08-22 19:23 ` Questions about Haifa scheduler Jeffrey A Law
1997-08-22 19:23 ` fixing the c++/f77 circular dependency Jim Wilson
1997-08-22 19:38 ` patches for libg++ Alexandre Oliva
1997-08-22 19:47 ` libstdc++ and gcc2 merge Jason Merrill
  -- strict thread matches above, loose matches on Subject: below --
1997-08-23 14:31 egcs-ss-970814 on m68k-next-nextstep3 Toon Moene
1997-08-23  4:37 Jim Wilson
1997-08-22 19:47 Toon Moene
1997-08-17 19:06 Toon Moene

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