Re: (fwd) K6 Issues

Re: (fwd) K6 Issues

[meissner]

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

Re: 970814: libU77/dtime_.c:73: #error Dont know clock tick length

[Jeffrey A Law]

  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

test results for egcs 970828 on alpha-dec-osf4.0

[scott snyder]

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.

Re: build on sparc-sun-sunos4.1.3

[Jeffrey A Law]

  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

Re: (fwd) K6 Issues

[Joern Rennecke]

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

I could get to the web site with the patch over the weekend.  It turns out
that this is a patch to make the stack in general unexecutable, and add
some ways to make it executable egain, including an option to detect gcc's
trampolines.

I can see how this can 'fix' the bug for the first trampoline a program
executes, since there will be exception handling to make the stack executable,
which will separate the writing of the trampoline from its actual execution;
however, this is a lot mor processing than seems necessary to merely avoid
the hardware bug for this first trampoline, and for all subsequent
trampolines, the stack will already be writable, hence the bug could still
manifest itself.

IMHO a better workaround for the hardware bug for trampolines is to add
some extra (conditional) code to TRAMPOLINE_TEMPLATE in i386.h

Re: (fwd) K6 Issues

[Joern Rennecke]

> The only self-modifying code I am aware of is trampolines.  Do you know
> any more about this?

Unfortunately, no.  I couldn't access the web site with the suggested
workaround either.

The AMD web page is up, and I can read their document with xpdf.
It looks to me like self-modifying code will work as long the modification
of the code is sufficiently separated from the execution; putting a jump to
a subroutine with 8 dummy instructions (I'm not sure if nops a are good
enough, but there are lots of insn combinations without a net effect on
register state) after the actual trampoline initialization should probably
qualify.

(fwd) K6 Issues

[Joern Rennecke]

Path: cygnus.co.uk!hose.news.pipex.net!pipex!rill.news.pipex.net!pipex!join.news.pipex.net!pipex!server1.netnews.ja.net!lyra.csx.cam.ac.uk!Cabal.CESspool!bofh.vszbr.cz!nntprelay.mathworks.com!howland.erols.net!infeed1.internetmci.com!newsfeed.internetmci.com!204.238.120.130!jump.net!jumpnet.com!news
From: Donovan Ready 
Newsgroups: comp.os.linux.hardware
Subject: K6 Issues
Date: Fri, 29 Aug 1997 13:38:07 -0500
Organization: Lindsay Computer Systems
Lines: 49
Message-ID: 
NNTP-Posting-Host: 207.8.14.7
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01GoldC-Caldera (X11; I; Linux 2.0.29 i586)
Xref: cygnus.co.uk comp.os.linux.hardware:14797

We initiated a problem report to AMD last week on the kernel compile
failures per the 'burnit' script.

AMD sent this response:

========================================================================
From: lee.little@amd.com
To: lcs@jumpnet.com
Subject: RE: AMD K6 Bug

Response for Email Questions Regarding Linux Re-compile Issue and If It
Affects Other Environments

AMD recently received reports from a limited number of users having
intermittent problems while running core re-compiles of the Linux
shareware operating system. Our systems engineering group has duplicated
the observation and determined that it is related to a previously known
erratum. Full technical details of this erratum are documented in
section 2.6.2 of the AMD-K6 MMX Enhanced Processor Revision Guide posted
on our website, www.amd.com. Due to the long list of rare conditions
necessary for this erratum to occur, the issue does not effect general
users in a DOS or Windows environment. It appears to be limited to
special cases as in the Linux kernal re-compile.

Users that feel they are being affected by this problem, should contact
AMD_s support line at (408) 749-3060 and ask for Dan Hingle or Glenn
Garcia.

========================================================================

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. 

We have been told of a patch at 
http://www.false.com/security/linux-stack, but the site is still down as
of 13:30 CDT.

If the compile passes, however, you will have a stable kernel. The
signal 11 and stack faults will stop the compile, of course, but the
thought of 'silent' failures is much less fearsome now. In the meantime,
it remains to be seen which camp will make changes. AMD told us that the
problem _would_ be addressed in a future stepping of the K6.

-- 

Donovan Ready,
Lindsay Computer Systems
http://www.jumpnet.com/~lcs

--
J"orn Rennecke