Re: Problems on PowerPC...

Re: Problems on PowerPC...

[dtm]

On Thu, 21 Aug 1997, Jim Wilson wrote:

> 	make CC="gcc" CFLAGS="-fsigned-char" LANGUAGES=c genattr
> 
> 	make CC="stage1/xgcc -Bstage1/" CFLAGS="-fsigned-char" LANGUAGES=c genattr
> 
> Try adding "-v" to CFLAGS.  This will show the linker command lines, which
> may show up an obvious difference.

Gotcha. (the following is formatted a bit for niceness...) 

>>>>>>>>>>
make CC="stage1/xgcc -Bstage1/" CFLAGS="-fsigned-char -v" \
	LANGUAGES=c genattr

stage1/xgcc -Bstage1/  -DIN_GCC    -fsigned-char -v  -DHAVE_CONFIG_H   -o
genattr \
 genattr.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
"stage1/xgcc -Bstage1/"@"" in "cc"@?*) echo  ;; esac ` ` case "" in ?*)
echo  ;; esac ` 

Reading specs from stage1/specs
gcc version egcs-2.90.00 970814 (gcc2-970802 experimental)

stage1/ld -m elf32ppc -o genattr /usr/lib/crt1.o /usr/lib/crti.o \
	stage1/crtbegin.o genattr.o rtl.o obstack.o stage1/libgcc.a -lc \
	stage1/libgcc.a stage1/crtend.o /usr/lib/crtn.o
<<<<<<<<<<
>>>>>>>>>>
make CC="gcc" CFLAGS="-fsigned-char -v" LANGUAGES=c genattr

gcc  -DIN_GCC    -fsigned-char -v  -DHAVE_CONFIG_H   -o genattr \
 genattr.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
"gcc"@"" in "cc"@?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 

Reading specs from
/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux/specs
gcc version 2.7.2.1-ppclinux

ld -dynamic-linker=/lib/ld.so.1 -o genattr /usr/lib/crt1.o \
	/usr/lib/crti.o /usr/lib/crtbegin.o \
	-L/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux \ 
	genattr.o rtl.o obstack.o \
	/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux/libgcc.a \
	-lc /usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux/libgcc.a \
	/usr/lib/crtend.o /usr/lib/crtn.o
<<<<<<<<<<

It looks like there's a difference in the ld command that's being
issued...but it also looks like there might be issues of dynamic
linking involved here when I'm using my normal gcc.  Egcs is providing
an '-m elf32ppc' argument that GCC isn't.  GCC is providing an
extra '-dynamic-linker=/lib/ld.so.1' argument that Egcs isn't.  

I've tried adding a '-Wl,-m,elf32ppc' to the CFLAGS of the make
with standard GCC, but that didn't cause it to produce a broken

 
> It is possible that collect2.c is doing something different that is
> causing a problem.  You can use -Wl,-debug to debug collect2.

The output from adding a -Wl,-debug to CFLAGS doesn't seem to 
indicate much of a difference between the egcs and gcc. The
only significant difference I noted was that all of the paths
were pointing to different places, and some of the ones used
in the egcs compile didn't exist.  I wouldn't think that's the
cause of the problem, though.  Perhaps I'll step through some
of the collect2 process in gdb...It seems to be the guy responsible
for making __CTOR_LIST__ and such...perhaps it's doing it wrong...
 
> Also, check your `normal-gcc' sources.  David Edelsohn implied that the
> linux-pmac gcc was different from FSF gcc, and if this is true, then you
> might be able to figure out what was added to the linux-pmac gcc sources
> that needs to be added to the FSF (and EGCS) gcc sources to make them
> work on a linux-pmac system.

I just started working on that.  No news yet...

Thanks,
-David

> Jim
> 

Re: g++ bug in recent gcc.

[H.J. Lu]

> 
> >>>>> H J Lu <hjl@lucon.org> writes:
> 
> > The reported libg++ failure is caused by the patch enclosed
> > here.
> 
> That patch is a necessary part of a large body of changes.  In any case,
> tmap seems to be work with the current sources; let me know if you still
> have problems with tonight's snapshot.
> 

I still have the same problem with egcs ss-970821. Backing out
your patch solved it. BTW, I am using -O -g on tmap.cc.

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

Re: g++ bug in recent gcc.

[Jason Merrill]

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

> The reported libg++ failure is caused by the patch enclosed
> here.

That patch is a necessary part of a large body of changes.  In any case,
tmap seems to be work with the current sources; let me know if you still
have problems with tonight's snapshot.

Jason

g++ bug in recent gcc.

[H.J. Lu]

Hi,

The reported libg++ failure is caused by the patch enclosed
here. After backing out this patch, I successfully did

# make
# make check

on libg++ 2.8b6 glibc 6 under Linux/x86


H.J.
---
Thu Jul 31 17:14:04 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* tree.c (build_cplus_new): Don't set TREE_ADDRESSABLE.

diff -rcp2N testgcc-970725/cp/tree.c testgcc-970803/cp/tree.c
*** testgcc-970725/cp/tree.c	Thu Jul 24 20:59:08 1997
--- testgcc-970803/cp/tree.c	Fri Aug  1 17:21:36 1997
*************** build_cplus_new (type, init)
*** 228,235 ****
  		TREE_OPERAND (init, 0), TREE_OPERAND (init, 1), slot);
    TREE_SIDE_EFFECTS (rval) = 1;
-   TREE_ADDRESSABLE (rval) = 1;
    rval = build (TARGET_EXPR, type, slot, rval, NULL_TREE, NULL_TREE);
    TREE_SIDE_EFFECTS (rval) = 1;
-   TREE_ADDRESSABLE (rval) = 1;
  
    return rval;
--- 228,233 ----