Xref: utzoo comp.windows.ms:4813 comp.os.msdos.programmer:723
Path: utzoo!utgpu!news-server.csri.toronto.edu!turing.toronto.edu!west
Newsgroups: comp.windows.ms,comp.os.msdos.programmer
From: west@turing.toronto.edu (Tom West)
Subject: Re: Microsoft Support (or lack of)
Message-ID: <1990Aug31.142549.21662@jarvis.csri.toronto.edu>
Organization: CSRI, University of Toronto
References: <1990Aug27.132321.24161@jarvis.csri.toronto.edu> <9121@ur-cc.UUCP> <1990Aug28.195832.1853@chinet.chi.il.us> <1990Aug30.222714.12127@mccc.uucp>
Distribution: na
Date: 31 Aug 90 18:25:49 GMT
Lines: 42

In article <9121@ur-cc.UUCP> bfag@uhura.cc.rochester.edu (Meneldur) writes:
>As for bug lists, the Microsoft database, also on Compu$erve and (I think) 
>GENIE, does pretty well in that regard.  I understand that it is the same
>database as is used by the technicians whom you call.

  If they publish their bug lists (Om my god, people will know that Microsoft
C 6.0 has bugs in it), why the hell won't they gives these out in any way to
people phoning for technical support.  I had figured that it was marketing
droids who figured it was better to put the screws to the people who had bought
the thing, rather than admit publicly that bugs existed.  Now I found out that
even that excuse isn't valid.  What the hell is going on?  Why can't MS 
distribute buglists for their compilers?  WHY DOESN'T TECH SUPPORT EVEN TELL
PEOPLE THAT THESE LISTS EXIST ON COMMERCIAL SERVICES???

					Tom West
					west@turing.toronto.edu

  Can anyone tell me how many bugs cause MSC to generate bad code (rather than
break the compiler)?  I've bought 6.0, have found one code generation bug 
through pure luck and am petrified that I am going to distribute another
code generation bug that I haven't found in a commercial product.  

For people's information:

Bug 1 : If you are optimizing with -Oe (register optimization), do *NOT*
	have any register variables in your program.  The manual says it
	ignores them but it lies.  In fact, when using FP, it will generate
	bad code that eventually overflows the FP stack after many passes,
	possibly well away from the bad code.  Removing the keyword 'register'
	from the program seems to solve the problem.

Bug 2 : The following function will generate fatal error C1001, compiler
	file @(#)emit.c:1.115', line 524 Contact Microsoft Product Support
	Services (who will tell you that yes, it's a bug) when compiling
	with cl -c -Alfu -Od -Gsr file.c

	extern double g (void);
	double f ()
	{
		return (g ());
	}
  The two bugs I have found are: