Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.bugs.sys5,comp.lang.c,comp.sys.att
Subject: Re: Possible Bug in fpcc Release 1.0
Message-ID: <6011@brl-smoke.ARPA>
Date: Tue, 23-Jun-87 13:23:47 EDT
Article-I.D.: brl-smok.6011
Posted: Tue Jun 23 13:23:47 1987
Date-Received: Fri, 26-Jun-87 05:46:36 EDT
References: <471@ncsugn.ncsu.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: world
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13
Xref: mnetor comp.bugs.sys5:133 comp.lang.c:2634 comp.sys.att:624

In article <471@ncsugn.ncsu.edu> emigh@ncsugn.UUCP (Ted H. Emigh) writes:
>	aline 37	: operand type mismatch
>		... operand #2 of "mmovwd": "%r7"
>	aline 39	: operand type mismatch
>		... operand #1 of "mfdivd3": "%r7"

One quite often encounters this type of error introduced into previously
valid code by so-called "optimizers".  It's definitely a bug in the C
optimizer, perhaps due to an improper template somewhere.  (Also see if
the M32 SGS optimixer* bug fixes I posted to comp.bugs.sys5 a couple of
months ago (as DMD SGS bugs) have been installed.)

*This was a typo, but it seemed too fortuitous to correct!