public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: (fwd) K6 Issues
@ 1997-08-29 23:14 meissner
  1997-08-29 23:24 ` 970814: libU77/dtime_.c:73: #error Dont know clock tick length Jeffrey A Law
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: meissner @ 1997-08-29 23:14 UTC (permalink / raw)
  To: egcs

| > We did so. AMD's Tech support _and_ one of our Linux customers report
| > that gcc and g++ use self-modifying code to optimize some functions, and
| > this is a definate no-no, according to the erratum. 
| 
| The only self-modifying code I am aware of is trampolines.  Do you know
| any more about this?

See the discussion in the Linux Kernel mailing list.  Basically signal delivery
also uses self modifying code (and I think gdb also), in addition to
trampolines.

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

* Re: 970814: libU77/dtime_.c:73: #error Dont know clock tick length
  1997-08-29 23:14 (fwd) K6 Issues meissner
@ 1997-08-29 23:24 ` Jeffrey A Law
  1997-08-29 23:32 ` build on sparc-sun-sunos4.1.3 Jeffrey A Law
  1997-08-29 23:32 ` test results for egcs 970828 on alpha-dec-osf4.0 scott snyder
  2 siblings, 0 replies; 10+ messages in thread
From: Jeffrey A Law @ 1997-08-29 23:24 UTC (permalink / raw)
  To: egcs

  In message you write:
  > 
  > This is for i386-pc-solaris2.5.1.
  > 
  > % as -v
  > GNU assembler version 2.8.1 (i386-pc-solaris2.5.1), using BFD version 2.8.1
  > 
  > I saw this after running make with -j2:
  > 
  >   gcc -g -DSTDC_HEADERS=1 -D_POSIX_SOURCE=1 -DRETSIGTYPE=void -DNON_ANSI_RW
  > _MODES=1 -DNO_EOF_CHAR_CHECK=1 -DSkip_f2c_Undefs=1 -DPad_UDread=1 -DWANT_LE
  > AD_0=1   -c libU77/dtime_.c -o libU77/dtime_.o
  >   libU77/dtime_.c:73: #error Dont know clock tick length
  >   make[1]: *** [libU77/dtime_.o] Error 1
  >   make[1]: *** Waiting for unfinished jobs....
  > 
  > Surprisingly, if I run make again after that failure, I don't see
  > the error again.
We checked in some of HJ's patches to address some parallel make issues,
particularly in the g77 subdirs.

Are you still having this problem?

jeff

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

* test results for egcs 970828 on alpha-dec-osf4.0
  1997-08-29 23:14 (fwd) K6 Issues meissner
  1997-08-29 23:24 ` 970814: libU77/dtime_.c:73: #error Dont know clock tick length Jeffrey A Law
  1997-08-29 23:32 ` build on sparc-sun-sunos4.1.3 Jeffrey A Law
@ 1997-08-29 23:32 ` scott snyder
  2 siblings, 0 replies; 10+ messages in thread
From: scott snyder @ 1997-08-29 23:32 UTC (permalink / raw)
  To: egcs

hi -

I just ran the testsuite using egcs 970828 on an alpha-dec-osf4.0 host.


Here's the gcc summary:

                === gcc Summary ===

# of expected passes            4857
# of unexpected failures        22
# of expected failures          4
# of unsupported tests          7

These are the tests which fail:


FAIL: gcc.c-torture/compile/961203-1.c,  -O0  
FAIL: gcc.c-torture/compile/961203-1.c,  -O1  
FAIL: gcc.c-torture/compile/961203-1.c,  -O2  
FAIL: gcc.c-torture/compile/961203-1.c,  -O2 -fomit-frame-pointer -finline-funct
FAIL: gcc.c-torture/execute/920411-1.c execution,  -O1
FAIL: gcc.c-torture/execute/920411-1.c execution,  -O2
FAIL: gcc.c-torture/execute/920411-1.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/920411-1.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/920411-1.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
FAIL: gcc.c-torture/execute/cbrt.c execution,  -O0 
FAIL: gcc.c-torture/execute/cbrt.c execution,  -O1 
FAIL: gcc.c-torture/execute/cbrt.c execution,  -O2 
FAIL: gcc.c-torture/execute/cbrt.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/complex-5.c execution,  -O0 
FAIL: gcc.c-torture/execute/complex-5.c execution,  -O1 
FAIL: gcc.c-torture/execute/complex-5.c execution,  -O2 
FAIL: gcc.c-torture/execute/complex-5.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.misc-tests/m-un-1.c (test for excess errors)



Here's the g++ summary:


                === g++ Summary ===

# of expected passes            3263
# of unexpected successes       5
# of expected failures          83
# of untested testcases         6

The unexpected successes are:

XPASS: g++.brendan/array1.C overflow in array dimension.* , (test for errors, line 6)
XPASS: g++.brendan/scope4.C (test for excess errors)
XPASS: g++.law/profile1.C (test for excess errors)
XPASS: g++.law/profile1.C  Execution test
XPASS: g++.mike/p7325.C *-*-* Execution test


Here's a brief analysis of the unexpected failures for the gcc check.


-- 961203-1.c ---------------------------------------------------------------
struct s {
  char a[0x32100000];
  int x:30, y:30;
};

int
main ()
{
  struct s* p;

  p = (struct s*) 0;
  if (p->x == p->y)
    exit (1);
}
-----------------------------------------------------------------------------

For these, i got an error:

Stack overflow: pid 22083, proc cc1, addr 0x11dffffe0, pc 0x12009e72c

and

xgcc: Internal compiler error: program cc1 got fatal signal 11



-- 920411-1.c ---------------------------------------------------------------
long f (w)
     char *w;
{
  long k, i, c = 0, x;
  char *p = (char*) &x;
  for (i = 0; i = 0;) a[i] = ' ';
  if (f (a) != ~0UL / (unsigned char) ~0 * ' ')
    abort ();
  exit (0);
}
-----------------------------------------------------------------------------

When this is compiled with -O1, f (a) returns 0.
It appears that gcc is not noticing the aliasing between
*p and x in f(): The store into p[k] is done directly into memory,
but the x used in c += x comes from a register.

Here's the generated code (with -O1):

	.verstamp 3 11
	.set noreorder
	.set volatile
	.set noat
	.arch ev4
	.file	1 "920411-1.c"
gcc2_compiled.:
__gnu_compiled_c:
.text
	.align 3
	.globl f
	.ent f
f:
f..ng:
	lda $30,-16($30)
	.frame $30,16,$26,0
	.prologue 0
	bis $31,$31,$0
	bis $30,$30,$6
	bis $0,$0,$5
	ldq $7,0($30)
	.align 5
$37:
	bis $31,$31,$4
	.align 5
$41:
	addq $6,$4,$3
	addq $16,$4,$2
	ldq_u $1,0($2)
	extbl $1,$2,$1
	ldq_u $2,0($3)
	mskbl $2,$3,$2
	insbl $1,$3,$1
	bis $1,$2,$1
	stq_u $1,0($3)
	addq $4,1,$4
	cmpule $4,7,$1
	bne $1,$41
	addq $0,$7,$0
	addq $5,1,$5
	ble $5,$37
	addq $30,16,$30
	ret $31,($26),1
	.end f
.rdata
	.quad 0
	.align 3
$C32:
	.quad 2314885530818453536
.text
	.align 3
	.globl main
	.ent main
main:
	ldgp $29,0($27)
main..ng:
	lda $30,-32($30)
	.frame $30,32,$26,0
	stq $26,0($30)
	.mask 0x4000000,-32
	.prologue 1
	bis $31,7,$4
	bis $31,32,$5
	.align 5
$48:
	addq $30,$4,$3
	addq $3,16,$3
	ldq_u $2,0($3)
	mskbl $2,$3,$2
	insbl $5,$3,$1
	bis $1,$2,$1
	stq_u $1,0($3)
	subl $4,1,$4
	bge $4,$48
	addq $30,16,$16
	bsr $26,f..ng
	lda $1,$C32
	ldq $1,0($1)
	subq $0,$1,$0
	beq $0,$50
	jsr $26,abort
	ldgp $29,0($26)
	.align 4
$50:
	bis $31,$31,$16
	jsr $26,exit
	ldgp $29,0($26)
	.align 4
	.end main



-- cbrt.c -------------------------------------------------------------------
/*
 * ====================================================
 * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
 *
 * Developed at SunPro, a Sun Microsystems, Inc. business.
 * Permission to use, copy, modify, and distribute this
 * software is freely granted, provided that this notice
 * is preserved.
 * ====================================================
*/

#ifndef __vax__
static const unsigned long
	B1 = 715094163, /* B1 = (682-0.03306235651)*2**20 */
	B2 = 696219795; /* B2 = (664-0.03306235651)*2**20 */

static const double
	C =  5.42857142857142815906e-01, /* 19/35     = 0x3FE15F15, 0xF15F15F1 */
	D = -7.05306122448979611050e-01, /* -864/1225 = 0xBFE691DE, 0x2532C834 */
	E =  1.41428571428571436819e+00, /* 99/70     = 0x3FF6A0EA, 0x0EA0EA0F */
	F =  1.60714285714285720630e+00, /* 45/28     = 0x3FF9B6DB, 0x6DB6DB6E */
	G =  3.57142857142857150787e-01; /* 5/14      = 0x3FD6DB6D, 0xB6DB6DB7 */

double
cbrtl (double x)
{
  long hx;
  double r,s,w;
  double lt;
  unsigned sign;
  union {
    double t;
    unsigned long pt[2];
  } ut, ux;
  int n0;

  ut.t = 1.0;
  n0 = (ut.pt[0] == 0);

  ut.t = 0.0;
  ux.t = x;

  hx = ux.pt[n0];			/* high word of x */
  sign=hx&0x80000000;			/* sign= sign(x) */
  hx  ^=sign;
  if(hx>=0x7ff00000) return(x+x);	/* cbrt(NaN,INF) is itself */
  if((hx| ux.pt[1-n0])==0)
    return(ux.t);			/* cbrt(0) is itself */

  ux.pt[n0] = hx;
  /* rough cbrt to 5 bits */
  if(hx

double nan = 1.0/0.0 - 1.0/0.0;
double x = 1.0;

void leave ()
{
  exit (0);
}

main ()
{
#if ! defined (__vax__) && ! defined (_CRAY)
  /* NaN is an IEEE unordered operand.  All these test should be false.  */
  if (nan == nan)
    abort ();
  if (nan != x)
    x = 1.0;
  else
    abort ();

#ifndef SIGNAL_SUPPRESS
  /* Some machines catches a SIGFPE when a NaN is compared.
     Let this test succeed o such machines.  */
  signal (SIGFPE, leave);
#endif

  if (nan  x)
    abort ();
  if (nan = x)
    abort ();
  if (nan == x)
    abort ();
#endif
  exit (0);
}
-----------------------------------------------------------------------------


On the alpha, the first test triggers a floating point exception.


-- m-un-1.c -----------------------------------------------------------------
/* m-un-1.c: "un" for "uninitialized" */

/*
From: Jim Wilson 
Date: Wed, 6 Jul 1994 13:11:47 -0700
To: dje@cygnus.com
Subject: Re: devo/gcc ChangeLog.fsf stmt.c
Cc: cvs-gcc@cygnus.com, tege@cygnus.com

	How about a test case?  :-)

Compile with -O -Wall and the broken compiler gives you:
tmp.c:6: warning: `k' might be used uninitialized in this function
The fixed compiler (and gcc 2.5.8) gives no warning.

This happens to fix a performance regression in the code generated for
while loops, but that is presumably much much harder to test for.
*/

/* { dg-do compile } */
/* { dg-options "-O -Wall" } */

int
sub ()
{
  int i = 0;
  int j = 0;
  int k;	/* { dg-bogus "`k' might be used uninitialized" "uninitialized warning regression" } */

  while (i == 0 && j == 0)
    {
      k = 10;
      i = sub ();
    }

  return k;
}
-----------------------------------------------------------------------------


This is compiled with the command

 /d0sgif/data1/snyder/egcs-build/ALPHA/gcc/xgcc -B/d0sgif/data1/snyder/egcs-build/ALPHA/gcc/ /d0sgif/data1/snyder/egcs/gcc/testsuite/gcc.misc-tests/m-un-1.c   -O -Wall -c  -o m-un-1.s

and gives the error

compiler exited with status 1
output is:
as: Error: -o m-un-1.s resembles the name of a source file, disallowed


.. this looks like a problem with the test harness.

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

* Re: build on sparc-sun-sunos4.1.3
  1997-08-29 23:14 (fwd) K6 Issues meissner
  1997-08-29 23:24 ` 970814: libU77/dtime_.c:73: #error Dont know clock tick length Jeffrey A Law
@ 1997-08-29 23:32 ` Jeffrey A Law
  1997-08-29 23:32 ` test results for egcs 970828 on alpha-dec-osf4.0 scott snyder
  2 siblings, 0 replies; 10+ messages in thread
From: Jeffrey A Law @ 1997-08-29 23:32 UTC (permalink / raw)
  To: egcs

  In message you write:
  > Here's a fix for this problem.  The main reason is that libiberty is
  > not multilib'ed, so there's not a libiberty directory in each multilib
  > dir, only in the main build directory.
I think that's just papering over the problem.

libiberty is supposed to be multilib'd just like libio, libstdc++
and libgcc.  So what we need to do is figure out why it wasn't
multilib'd.

jeff

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

* Re: build on sparc-sun-sunos4.1.3
  1997-08-30  4:22 build on sparc-sun-sunos4.1.3 Jim Wilson
@ 1997-09-01 16:56 ` Jim Wilson
  0 siblings, 0 replies; 10+ messages in thread
From: Jim Wilson @ 1997-09-01 16:56 UTC (permalink / raw)
  To: egcs; +Cc: Jason Merrill, Kate Hedstrom

	Because libiberty is a host library, and only target libraries are
	multilibbed.  The target libiberty for a native is never built.  Solutions
	welcome.

I have installed a patch to fix this using the same method that works for
the irix6 port.  Namely, I added code to set target_subdir.

However, instead of using ${host} or ${host_alias}, which might not be a
valid filename for the target (e.g. may be more than 14 characters), I
decided to use `libraries'.  This should be OK for any UNIX machine.
It probably doesn't matter that it is not OK for other machines (e.g.
DOS, VMS), since we can always disable multilibbing for them.  Or, we
can change the filename later if necessary.  I kind of liked the choice
`libraries' though.

Mon Sep  1 16:45:44 1997  Jim Wilson  <wilson@cygnus.com>

	* configure.in (target_subdir): Set to libraries if enable_multilib.

Index: configure.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/configure.in,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 configure.in
*** configure.in	1997/08/21 22:57:39	1.1.1.1
--- configure.in	1997/09/01 23:45:23
*************** if [ x"${host}" = x"${target}" ] ; then
*** 244,255 ****
  	# that are in the 'cross only' list
  	skipdirs="${skipdirs} ${cross_only}"
  	is_cross_compiler=no
! 	target_subdir=.
! 	case "${host}" in
!           # We need multilib support for irix6, to get libiberty built
! 	  #  properly for o32 and n32.
!           mips-sgi-irix6*) target_subdir=${host} ;;
! 	esac
  else
  	# similarly, don't build the targets in the 'native only' 
  	# list when building a cross compiler
--- 244,255 ----
  	# that are in the 'cross only' list
  	skipdirs="${skipdirs} ${cross_only}"
  	is_cross_compiler=no
! 	# Default to --enable-multilib.  See similar code below.
! 	if [ x${enable_multilib} = xno ]; then
! 	  target_subdir=.
! 	else
! 	  target_subdir=libraries
! 	fi
  else
  	# similarly, don't build the targets in the 'native only' 
  	# list when building a cross compiler



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

* Re: build on sparc-sun-sunos4.1.3
@ 1997-08-30  4:22 Jim Wilson
  1997-09-01 16:56 ` Jim Wilson
  0 siblings, 1 reply; 10+ messages in thread
From: Jim Wilson @ 1997-08-30  4:22 UTC (permalink / raw)
  To: egcs

	Because libiberty is a host library, and only target libraries are
	multilibbed.  The target libiberty for a native is never built.  Solutions
	welcome.

It does get built multilibbed for Irix6.  However, this is due to a small
hack in configure.in.

Thu Jun 19 14:16:42 1997  Brendan Kehoe  

	* configure.in: Don't set ENABLE_MULTILIB, so we'll be passing
	--enable-multilib down to subdirs; setting TARGET_SUBDIR was enough.

Tue Jun 17 15:31:20 1997  Brendan Kehoe  

	* configure.in: If we're building mips-sgi-irix6* native, turn on
	ENABLE_MULTILIB and set TARGET_SUBDIR.

Search for mips-sgi-irix6, and note that it does
	target_subdir=.
	case "${host}" in
          # We need multilib support for irix6, to get libiberty built
	  #  properly for o32 and n32.
          mips-sgi-irix6*) target_subdir=${host} ;;
	esac

In the worst case, we could just always set target_subdir.  I think that
the only bad thing that happens is that libiberty gets built exactly the
same way twice for all natives (except irix6), once in libiberty, and once in
$target/libiberty.  This makes the build slower, and take up more space,
but otherwise is not a problem.

A more intelligent fix is to only set target_subdir if multilibbing is
enabled.

Jim

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

* Re: build on sparc-sun-sunos4.1.3
  1997-08-30  2:57 "restrict" keyword for C Jim Wilson
@ 1997-08-30  3:24 ` Jason Merrill
  0 siblings, 0 replies; 10+ messages in thread
From: Jason Merrill @ 1997-08-30  3:24 UTC (permalink / raw)
  To: egcs

>>>>> Jeffrey A Law  writes:

> libiberty is supposed to be multilib'd just like libio, libstdc++
> and libgcc.  So what we need to do is figure out why it wasn't
> multilib'd.

Because libiberty is a host library, and only target libraries are
multilibbed.  The target libiberty for a native is never built.  Solutions
welcome.

Jason

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

* Re: build on sparc-sun-sunos4.1.3
  1997-08-28  8:21 HAVE_STDLIB_H Craig Burley
@ 1997-08-28  8:21 ` Alexandre Oliva
  0 siblings, 0 replies; 10+ messages in thread
From: Alexandre Oliva @ 1997-08-28  8:21 UTC (permalink / raw)
  To: egcs

--Multipart_Thu_Aug_28_01:51:32_1997-1
Content-Type: text/plain; charset=US-ASCII

Jeffrey A Law writes:

>   In message <199708261407.KAA19260@ahab.rutgers.edu>you write:

>> I got the following error when doing "configure; make":
>> /bin/sh: ../libiberty: bad directory

> Hmm, weird, not sure what would cause this... I'll look into it.

Here's a fix for this problem.  The main reason is that libiberty is
not multilib'ed, so there's not a libiberty directory in each multilib
dir, only in the main build directory.

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

--Multipart_Thu_Aug_28_01:51:32_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="libiberty.diff"
Content-Transfer-Encoding: 7bit

--- libstdc++/Makefile.in~	Wed Aug 27 02:03:49 1997
+++ libstdc++/Makefile.in	Thu Aug 28 01:17:00 1997
@@ -42,7 +42,7 @@
 ##
 
 IO_DIR    = ../libio
-LIBIBERTY_DIR = ../libiberty
+LIBIBERTY_DIR = $(MULTIBUILDTOP)../libiberty
 
 LIBIBERTY_OBJS = `cat $(LIBIBERTY_DIR)/needed-list` strerror.o
 

--Multipart_Thu_Aug_28_01:51:32_1997-1--

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

* Re: build on sparc-sun-sunos4.1.3
  1997-08-27  1:44 Insulting comments in cpp.texi Joe Buck
@ 1997-08-27  2:17 ` Jeffrey A Law
  0 siblings, 0 replies; 10+ messages in thread
From: Jeffrey A Law @ 1997-08-27  2:17 UTC (permalink / raw)
  To: egcs

  In message <199708261407.KAA19260@ahab.rutgers.edu>you write:
  > I got the following error when doing "configure; make":
  > 
  > cd ../libiberty ; make "INSTALL=/bin/sh
  > /d0/kate/gnu/egcs-970825/install-sh -c" "INSTALL_DATA=/bin/sh
  > /d0/kate/gnu/egcs-970825/install-sh -c -m 644" "INSTALL_PROGRAM=/bin/sh
  > /d0/kate/gnu/egcs-970825/install-sh -c " "prefix=/usr/local"
  > "exec_prefix=/usr/local" "tooldir=/usr/local/sparc-sun-sunos4.1.3"
  > "AR=ar" "AR_FLAGS=rc" "CC=/d0/kate/gnu/egcs-970825/gcc/xgcc
  > -B/d0/kate/gnu/egcs-970825/gcc/" "CXX=/d0/kate/gnu/egcs-970825/gcc/xgcc
  > -B/d0/kate/gnu/egcs-970825/gcc/" "CFLAGS=-g -O2  -fpic" "CXXFLAGS=-g
  > -O2  -fpic" "NM=nm" "RANLIB=ranlib" "LIBCFLAGS=-g -O2  -fpic"
  > "LIBCXXFLAGS=-g -O2 -fno-implicit-templates  -fpic" "LOADLIBES="
  > "LDFLAGS=" "MAKEINFO=/d0/kate/gnu/egcs-970825/texinfo/makeinfo/makeinfo
  > " "SHLIB=libstdc++.so.2.8.0" "SHCURSES=" "PICFLAG=" "RUNTESTFLAGS="
  > /bin/sh: ../libiberty: bad directory
Hmm, weird, not sure what would cause this... I'll look into it.


  >    ucpic/libstdc++
  >    v8/libstdc++
  >    pic/v8/libstdc++
  >    ucpic/v8/libstdc++
  > 
  > Should all these libstdc++ directories exist?  I am using gnu make if
  > that matters.
Yup.  They're "multilibs"; basically when you have multiple cpu
variants in the family (like 68000 vs 68020) multilibs allow the
runtime libraries to be built multiple times so that specifying
-m68000 will get you 68000 code generation _and_ 68000 specific
libraries at link time.

These are similar, but for the sparc port, which has different
libraries for -fPIC, -fpic and other stuff.

jeff

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

* build on sparc-sun-sunos4.1.3
  1997-08-26 13:14 virtual functions but non-virtual destructor David McWherter
@ 1997-08-26 13:14 ` Kate Hedstrom
  0 siblings, 0 replies; 10+ messages in thread
From: Kate Hedstrom @ 1997-08-26 13:14 UTC (permalink / raw)
  To: egcs

I got the following error when doing "configure; make":

cd ../libiberty ; make "INSTALL=/bin/sh
/d0/kate/gnu/egcs-970825/install-sh -c" "INSTALL_DATA=/bin/sh
/d0/kate/gnu/egcs-970825/install-sh -c -m 644" "INSTALL_PROGRAM=/bin/sh
/d0/kate/gnu/egcs-970825/install-sh -c " "prefix=/usr/local"
"exec_prefix=/usr/local" "tooldir=/usr/local/sparc-sun-sunos4.1.3"
"AR=ar" "AR_FLAGS=rc" "CC=/d0/kate/gnu/egcs-970825/gcc/xgcc
-B/d0/kate/gnu/egcs-970825/gcc/" "CXX=/d0/kate/gnu/egcs-970825/gcc/xgcc
-B/d0/kate/gnu/egcs-970825/gcc/" "CFLAGS=-g -O2  -fpic" "CXXFLAGS=-g
-O2  -fpic" "NM=nm" "RANLIB=ranlib" "LIBCFLAGS=-g -O2  -fpic"
"LIBCXXFLAGS=-g -O2 -fno-implicit-templates  -fpic" "LOADLIBES="
"LDFLAGS=" "MAKEINFO=/d0/kate/gnu/egcs-970825/texinfo/makeinfo/makeinfo
" "SHLIB=libstdc++.so.2.8.0" "SHCURSES=" "PICFLAG=" "RUNTESTFLAGS="
/bin/sh: ../libiberty: bad directory
make[3]: *** [../libiberty/libiberty.a] Error 1
make[3]: Leaving directory `/d0/kate/gnu/egcs-970825/pic/libstdc++'
make[2]: *** [multi-do] Error 1
make[2]: Leaving directory `/d0/kate/gnu/egcs-970825/libstdc++'
make[1]: *** [multi-all] Error 2
make[1]: Leaving directory `/d0/kate/gnu/egcs-970825/libstdc++'
make: *** [all-target-libstdc++] Error 2


I patched the pic/libstdc++ Makefile only to have it happen again in:

   ucpic/libstdc++
   v8/libstdc++
   pic/v8/libstdc++
   ucpic/v8/libstdc++

Should all these libstdc++ directories exist?  I am using gnu make if
that matters.  The "make install" worked and the few compiles I tried
so far worked.

Thanks for taking on this egcs project!  I think it is a great idea.

Kate
--
Kate Hedstrom               Institute of Marine and Coastal Sciences
kate@imcs.rutgers.edu       Rutgers University

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

end of thread, other threads:[~1997-09-01 16:56 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-29 23:14 (fwd) K6 Issues meissner
1997-08-29 23:24 ` 970814: libU77/dtime_.c:73: #error Dont know clock tick length Jeffrey A Law
1997-08-29 23:32 ` build on sparc-sun-sunos4.1.3 Jeffrey A Law
1997-08-29 23:32 ` test results for egcs 970828 on alpha-dec-osf4.0 scott snyder
  -- strict thread matches above, loose matches on Subject: below --
1997-08-30  4:22 build on sparc-sun-sunos4.1.3 Jim Wilson
1997-09-01 16:56 ` Jim Wilson
1997-08-30  2:57 "restrict" keyword for C Jim Wilson
1997-08-30  3:24 ` build on sparc-sun-sunos4.1.3 Jason Merrill
1997-08-28  8:21 HAVE_STDLIB_H Craig Burley
1997-08-28  8:21 ` build on sparc-sun-sunos4.1.3 Alexandre Oliva
1997-08-27  1:44 Insulting comments in cpp.texi Joe Buck
1997-08-27  2:17 ` build on sparc-sun-sunos4.1.3 Jeffrey A Law
1997-08-26 13:14 virtual functions but non-virtual destructor David McWherter
1997-08-26 13:14 ` build on sparc-sun-sunos4.1.3 Kate Hedstrom

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