From owner-freebsd-bugs  Tue Feb 11 15:30:12 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA28558
          for bugs-outgoing; Tue, 11 Feb 1997 15:30:12 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA28550
          for <freebsd-bugs@FreeBSD.org>; Tue, 11 Feb 1997 15:30:09 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by who.cdrom.com (8.7.5/8.6.11) with SMTP id PAA02149
          for <freebsd-bugs@FreeBSD.org>; Tue, 11 Feb 1997 15:28:18 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA21155; Tue, 11 Feb 1997 18:20:03 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 11 Feb 1997 18:20 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id QAA10203; Tue, 11 Feb 1997 16:55:48 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id RAA03232; Tue, 11 Feb 1997 17:00:19 -0500 (EST)
Date: Tue, 11 Feb 1997 17:00:19 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199702112200.RAA03232@lakes.water.net>
To: ponds!FreeBSD.org!freebsd-hackers@ucbvax.Berkeley.EDU,
        ponds!mitre.org!guhl@ucbvax.Berkeley.EDU
Subject: Re: Fix to Interrupt/Terminate Signal causes page fault in kernel mode
Cc: ponds!FreeBSD.org!freebsd-bugs@ucbvax.Berkeley.EDU
Content-Type: text
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> I posted the following to freebsd-hackers and freebsd-bugs a couple
> of days ago.   I have fixed the problem, not by making any code
> changes, but by compiling the kernel unoptimized!
> 
> compiler: GNU gcc version 2.6.3
> 
> I question the wisdom of allowing the COPTFLAGS option in
> /sys/386/conf/Makefile.i386 to enable optimization when
> this may cause unpredictable and erroneous kernel behavior.
> 
> Any opinions?
> 

 Yep -
 
  As a compiler writer, I "hear" this all the time.

  There are several situations where erroneous C code can
  behave this way.  Usually, these involve taking the address
  of an automatic variable, and saving that after the routine
  has ended.

  Also, in this situation, a common occurrence is to overwrite
  the end of an automatic array, or other variable.  When compiled
  optimized, the frame is frequently reordered, or the function has
  fewer temporaries; so you are more likely to write over other
  "meaningful" data.

  Only after I have eliminated those two possibilities do I begin
  to investigate compiler bugs.

	- Dave Rivers -