>Number:         5132
>Category:       bin
>Synopsis:       g++ -O3 produces wrong code at least on motorola 68060
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar  7 16:50:01 1998
>Last-Modified:
>Originator:     Ingolf Koch
>Organization:

Ingolf Koch         http://www.minet.uni-jena.de/~ingolf/
FSU Jena, Institut fuer Angewandte Mathematik, 07740 Jena
>Release:        NetBSD-1.3
>Environment:
System: NetBSD maus.rz.uni-jena.de 1.3 NetBSD 1.3 (MAUS) #0: Wed Jan 7 18:50:19 MET 1998 ingolf@maus.rz.uni-jena.de:/usr/src/sys/arch/amiga/compile/MAUS amiga
	Motorola 68060 processor

>Description:
	g++ produces wrong code when using optimization level 3.
	Compile in /usr/src/gnu/usr.bin/groff/eqn with -O3.
	The resulting binary behaves different than when compiling
	with -O2 or below:
	With -O3, you get (on a 68060 processor) a failed assertion
	when calling the eqn binary without any arguments:
	"Failed assertion at line 87, file `text.cc'." followed by
	a core dump (Abort trap in kill())
	With -O2 or less, the assertion does not fail for the eqn
	binary called with no arguments.

	"Real life" use of eqn (i.e. with argument(s)) shows similar
	results.

	Adding "-m68060 -Wa,-m68060" to CFLAGS/CXXFLAGS does not
	change the different behaviour.

	Maybe the core dump after the failed assertion should be
	another PR...

	BTW bash-2.01, when compiled with -O3, terminates with an
	Abort trap, too, while working well when compiled with -O2.
>How-To-Repeat:
	On a NetBSD-1.3 system with motorola 68060 processor, compile
	in /usr/src/gnu/usr.bin/groff/eqn with -O3. After that, call
	the eqn binary without arguments and watch it dump core due
	to a failed assertion.
	Compare it to compiling with -O2 or less which does not lead
	to the failed assertion.
>Fix:
>Audit-Trail:
>Unformatted: