From mi@privatelabs.com  Tue Jun 13 09:24:09 2000
Return-Path: <mi@privatelabs.com>
Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [198.143.31.30])
	by hub.freebsd.org (Postfix) with ESMTP id 5D03C37BF03
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 13 Jun 2000 09:24:05 -0700 (PDT)
	(envelope-from mi@privatelabs.com)
Received: from misha.privatelabs.com (root@misha.privatelabs.com [198.143.31.6])
	by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id MAA25696
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 13 Jun 2000 12:22:34 -0400
Received: (from mi@localhost)
	by misha.privatelabs.com (8.9.3/8.9.3) id MAA61270;
	Tue, 13 Jun 2000 12:23:01 -0400 (EDT)
	(envelope-from mi)
Message-Id: <200006131623.MAA61270@misha.privatelabs.com>
Date: Tue, 13 Jun 2000 12:23:01 -0400 (EDT)
From: Mikhail Teterin <mi@privatelabs.com>
Reply-To: mi@aldan.algebra.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: -fexpensive-optimizations buggy (even with -O)
X-Send-Pr-Version: 3.2

>Number:         19245
>Category:       i386
>Synopsis:       -fexpensive-optimizations buggy (even with -O)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    obrien
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 13 09:30:00 PDT 2000
>Closed-Date:    Thu Jun 28 18:17:43 GMT 2007
>Last-Modified:  Thu Jun 28 18:17:43 GMT 2007
>Originator:     Mikhail Teterin
>Release:        FreeBSD 4.0-STABLE i386
>Organization:
Virtual Estates, Inc.
>Environment:

	CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU)
	Pentium Pro MTRR support enabled


>Description:

	The attached piece of code, when compiled with
	``-O -fexpensive-optimizations'', produces incorrect
	binary on FreeBSD-4.0 .

	I tested the same compiler line on Mandrake Linux (an
	identical machine hardware-wise) and it compiles correctly.

	Mandrake's cc is the same as on FreeBSD:

		Reading specs from
			/usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs
		gcc version 2.95.2 19991024 (release)
			vs. our
		Using builtin specs.
		gcc version 2.95.2 19991024 (release)

	But their assembler is newer:

		GNU assembler version 2.9.5 (i686-pc-linux-gnu)
		using BFD version 2.9.5.0.16
			vs. our
		GNU assembler version 2.9.1 (i386-unknown-freebsdelf),
		using BFD version 2.9.1

>How-To-Repeat:

	Save the C-code below into a file bug.c. Then compile it with
		cc -O -fexpensive-optimizations bug.c -o bug

	As you can see from the code, the hostname output by both
	printfs shoud be the same, and on Linux and on FreeBSD without
	the -fexpensive-optimizations flag it is:

	Calling rfc1035QuestionPack with hostname 0xbffffe32 (./bug)
	In rfc1035QuestionPack: hostname is 0xbffffe32 (./bug)

	Yet, with the -fexpensive-optimizations flag, the hostname
	argument is passed in the register, which, apparently, is
	sometimes not loaded with the value and remains zero, resulting
	in:

	Calling rfc1035QuestionPack with hostname 0xbfbff8f0 (./bug)
	In rfc1035QuestionPack: hostname is 0x0 ((null))

	The code is stripped from the squid23's lib/rfc1035.c (I found
	this because squid was crashing on every request and restarting)
	-- I tried to reduce it to the bare minimum needed to reproduce
	the bug.

	/* beginning of end.c */

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <assert.h>
#include <strings.h>

static off_t
rfc1035QuestionPack(char *buf,
    size_t sz,
    const char *hostname,
    unsigned short class
    )
{
    off_t off = 0;
    unsigned short s;
    printf("In rfc1035QuestionPack: hostname is %p (%s)\n",
	hostname, hostname);
    s = htons(class);
    memcpy(buf + off, &s, sizeof(s));
    off += sizeof(s);
    assert(off <= sz);
    return off;
}

static unsigned short
rfc1035BuildAQuery(const char *hostname, char *buf, size_t sz)
{
    off_t offset = 0;
    printf("Calling rfc1035QuestionPack with hostname %p (%s)\n",
	hostname, hostname);
    offset += rfc1035QuestionPack(buf + offset,
	sz - offset,
	hostname,
	1
    );
    return 0;
}

int main(int argc, char *argv[]) {
	char buf[1024];
	rfc1035BuildAQuery(argv[argc - 1], buf, 1024);
	return 0;
}
	/* end of bug.c */

>Fix:
	Get the new assembler/binutils and add -fno-expensive-optimizations
	to all CFLAGS in the meantime. Anything else?

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: mi@aldan.algebra.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Wed, 14 Jun 2000 19:37:28 +1000 (EST)

 On Tue, 13 Jun 2000, Mikhail Teterin wrote:
 
 > >Description:
 > 
 > 	The attached piece of code, when compiled with
 > 	``-O -fexpensive-optimizations'', produces incorrect
 > 	binary on FreeBSD-4.0 .
 > 
 > 	I tested the same compiler line on Mandrake Linux (an
 > 	identical machine hardware-wise) and it compiles correctly.
 
 This is hard to explain, since the bug shown by your example is in gcc
 (2.95.2), not in the assembler or linker.
 
 > static off_t
 > rfc1035QuestionPack(char *buf,
 >     size_t sz,
 >     const char *hostname,
 >     unsigned short class
 >     )
 > {
 >     off_t off = 0;
 >     unsigned short s;
 >     printf("In rfc1035QuestionPack: hostname is %p (%s)\n",
 > 	hostname, hostname);
 >     s = htons(class);
 >     memcpy(buf + off, &s, sizeof(s));
 >     off += sizeof(s);
 >     assert(off <= sz);
 >     return off;
 > }
 
 gcc -O -fexpensive-optimizations reuses the stack space for `hostname' and
 `class', and zeros this space to initialize `off' before loading `hostname'
 or `class'.
 
 > 	Yet, with the -fexpensive-optimizations flag, the hostname
 > 	argument is passed in the register, which, apparently, is
 > 	sometimes not loaded with the value and remains zero, resulting
 > 	in:
 
 No, -fexpensive-optimizations doesn't affect the function call protocol.
 Args are still passed on the stack.
 
 > >Fix:
 > 	Get the new assembler/binutils and add -fno-expensive-optimizations
 > 	to all CFLAGS in the meantime. Anything else?
 
 Don't use -O2 (which enables -fexpensive-optimizations) unless you want to
 find bugs like this :-).
 
 Bruce
 
 

From: mi@privatelabs.com
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Wed, 14 Jun 2000 12:08:17 -0400 (EDT)

 On 14 Jun, Bruce Evans wrote:
 
 = >  The   attached   piece   of   code,   when   compiled   with   ``-O
 = >  -fexpensive-optimizations'',    produces   incorrect    binary   on
 = >  FreeBSD-4.0.
 = > 
 = >  I tested  the same  compiler line on  Mandrake Linux  (an identical
 = >  machine hardware-wise) and it compiles correctly.
 = 
 = This is hard to explain, since the bug shown by your example is in gcc
 = (2.95.2), not in the assembler or linker.
 
 Oh,  I  know  so  little...  But  I can  give  an  interested  party  an
 account  on  the  machine  to  verify this...  May  be,  it  the  specs?
 
 AFAIK, the function calls are done differently on Linux -- could that be
 the reason (with gcc mostly developed  on Linux (right?) -- they may not
 have cought all the bugs on other OSes)?
 
 = Don't  use -O2  (which enables  -fexpensive-optimizations) unless  you
 = want to find bugs like this :-).
 
 That's  the  thing  --  I  only  asked for  -O  but  with  the  explicit
 -fexpensive-optimizations. Will -ON ever be reliable for N>1 ?
 
 	-mi
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 20:12:42 PDT 2001 
State-Changed-Why:  

GCC has major problems with optimisation.  See bde's comments for 
details. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19245 

From: Mike Barcroft <mike@FreeBSD.org>
To: Mikhail Teterin <mi@aldan.algebra.com>
Cc: bde@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Mon, 23 Jul 2001 16:07:29 -0400

 On Mon, Jul 23, 2001 at 12:21:58PM -0400, Mikhail Teterin wrote:
 > On 21 Jul, mike@FreeBSD.org wrote:
 > > Synopsis: -fexpensive-optimizations buggy (even with -O)
 > > 
 > > State-Changed-From-To: open->closed
 > > State-Changed-By: mike
 > > State-Changed-When: Sat Jul 21 20:12:42 PDT 2001
 > > State-Changed-Why: 
 > > 
 > > GCC has major problems with optimisation.  See bde's comments for
 > > details.
 > 
 > First, BDE did not close the PR himself, despite his comments. Second,
 > the same "troublesome" GCC produces correct code on Linux, which was
 > one of the major points of my PR -- something was/is wrong with the
 > FreeBSD-specific part of gcc-2.95.2... But, it seems, you are on a
 > PR-closing trip...
 
 Sorry if this was made unclear.  GCC is known to do bad things when
 using anything but -O for optimisation on FreeBSD.  This has been
 discussed numerous times on the mailing lists.  Also, we directly
 import vendor code, so this problem must be fixed by the GCC people.
 A quick search of the GCC Gnats database reveals many bug reports
 involving optimisation problems.  If your problem isn't addressed
 in one of those PR's, may I recommend you open a new one there?
 
 There could be any number of reasons why Bruce didn't close your
 PR then and there.  Bruce is a very busy person and might not have
 had time to close this PR.  I'm CC'ing Bruce on this message to
 see if I missed something in his comments that would require this
 PR to be left open.
 
 It may seem as though I'm on a "PR-closing trip" to you, but I
 assure you my intentions are to determine if problems from years
 ago are still problems today.  There are many PR's in our datebase
 that should have been closed a long time ago.  I feel this PR is
 one of them.
 
 Best regards,
 Mike Barcroft

From: Bruce Evans <bde@zeta.org.au>
To: Mike Barcroft <mike@FreeBSD.org>
Cc: Mikhail Teterin <mi@aldan.algebra.com>, <bde@FreeBSD.org>,
	<freebsd-gnats-submit@FreeBSD.org>
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Wed, 29 Aug 2001 22:27:24 +1000 (EST)

 On Mon, 23 Jul 2001, Mike Barcroft wrote:
 
 > On Mon, Jul 23, 2001 at 12:21:58PM -0400, Mikhail Teterin wrote:
 > > On 21 Jul, mike@FreeBSD.org wrote:
 > > > GCC has major problems with optimisation.  See bde's comments for
 > > > details.
 > >
 > > First, BDE did not close the PR himself, despite his comments. Second,
 > > the same "troublesome" GCC produces correct code on Linux, which was
 > > one of the major points of my PR -- something was/is wrong with the
 > > FreeBSD-specific part of gcc-2.95.2... But, it seems, you are on a
 > > PR-closing trip...
 >
 > Sorry if this was made unclear.  GCC is known to do bad things when
 > using anything but -O for optimisation on FreeBSD.  This has been
 > ...
 > There could be any number of reasons why Bruce didn't close your
 > PR then and there.  Bruce is a very busy person and might not have
 > had time to close this PR.  I'm CC'ing Bruce on this message to
 > see if I missed something in his comments that would require this
 
 The main reason reason is that I wasn't sure that it was not a FreeBSD
 bug.  There is now a near-duplicate of this PR (gnu/30181) which says
 that the bug is in both the FreeBSD port and original GNU version of
 gcc-2.95.3, and analyses generated code to locate the wrong instructions.
 It's clear that it is a gcc bug.
 
 I don't plan to fix this.  PR 30181 suggests mentioning the problem in
 the release notes.  This seems reasonable.  I think the PRs should be
 cross-refernced, and closed after doing this.
 
 Bruce
 

From: Mikhail Teterin <mi@aldan.algebra.com>
To: bde@zeta.org.au
Cc: mike@FreeBSD.org, bde@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Wed, 29 Aug 2001 18:07:06 -0400 (EDT)

  
 > The main reason reason is that I wasn't sure that it was not a FreeBSD
 > bug. There is  now a near-duplicate of this PR  (gnu/30181) which says
 > that the  bug is  in both  the FreeBSD port  and original  GNU version
 > of  gcc-2.95.3,  and  analyses  generated code  to  locate  the  wrong
 > instructions. It's clear that it is a gcc bug.
 
 But on  the Mandrake the same  code compiles correctly --  that's what I
 don't understand. In fact, that's the only  reason I filed the PR at all
 -- I know about optimization problems in gcc in general.
 
 Did Mandrake patch the compiler somehow? Can we incorporate their fix?
 
 	-mi
 
 

From: Bruce Evans <bde@zeta.org.au>
To: Mikhail Teterin <mi@aldan.algebra.com>
Cc: <mike@FreeBSD.org>, <bde@FreeBSD.org>,
	<freebsd-gnats-submit@FreeBSD.org>
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Thu, 30 Aug 2001 23:45:16 +1000 (EST)

 On Wed, 29 Aug 2001, Mikhail Teterin wrote:
 
 > > The main reason reason is that I wasn't sure that it was not a FreeBSD
 > > bug. There is  now a near-duplicate of this PR  (gnu/30181) which says
 > > that the  bug is  in both  the FreeBSD port  and original  GNU version
 > > of  gcc-2.95.3,  and  analyses  generated code  to  locate  the  wrong
 > > instructions. It's clear that it is a gcc bug.
 >
 > But on  the Mandrake the same  code compiles correctly --  that's what I
 > don't understand. In fact, that's the only  reason I filed the PR at all
 > -- I know about optimization problems in gcc in general.
 >
 > Did Mandrake patch the compiler somehow? Can we incorporate their fix?
 
 Maybe they just use obrien's hack to silently force -O2 down to -O1 :-).
 (WANT_FORCE_OPTIMIZATION_DOWNGRADE=1 in /etc/make.conf in -current.)
 
 Bruce
 
Responsible-Changed-From-To: freebsd-bugs->obrien 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Thu Aug 30 13:08:10 PDT 2001 
Responsible-Changed-Why:  
Uggg.. someone really should have made me aware of this PR. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19245 
State-Changed-From-To: closed->open 
State-Changed-By: obrien 
State-Changed-When: Thu Aug 30 13:16:51 PDT 2001 
State-Changed-Why:  
Uh, this should have NEVER have been closed, but rather assigned to me. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19245 
State-Changed-From-To: open->closed 
State-Changed-By: ashp 
State-Changed-When: Thu Jan 17 19:21:31 PST 2002 
State-Changed-Why:  
Now that obrien has stepped down as GCC maintainer, I feel this should be 
closed again.  We don't have the manpower to fix bugs within GCC itself. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19245 
State-Changed-From-To: closed->open 
State-Changed-By: obrien 
State-Changed-When: Wed Jan 23 04:19:16 PST 2002 
State-Changed-Why:  
DO NOT FSCKING EVER CLOSE A PR ASSIGNED TO ME W/O ASKING ME FIRST!! 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19245 

From: Matteo Riondato <matteo@FreeBSD.ORG>
To: bug-followup@FreeBSD.org, mi@aldan.algebra.com
Cc:  
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Sat, 27 Aug 2005 14:09:26 +0200

 Can this PR be closed?
 -- 
 Matteo Riondato
 FreeBSD Volunteer (http://www.FreeBSD.org/)
 GUFI Staff Member (http://www.GUFI.org/)
 FreeSBIE Developer (http://www.FreeSBIE.org/)

From: Ceri Davies <ceri@FreeBSD.org>
To: obrien@FreeBSD.org
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: i386/19245: -fexpensive-optimizations buggy (even with -O)
Date: Sun, 8 Oct 2006 18:55:30 +0100

 Is the problem in this PR still outstanding?  If not, can we close the
 PR please?
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Thu Jun 28 18:17:40 UTC 2007 
State-Changed-Why:  
No reply since a long long time, I am closing this PR. If you have 
feedback obrien please post it and consider reopening it, if not then 
the right thing is done :) hat: bugmeister 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19245 
>Unformatted:
