From steve@mail.yahoo.com  Mon Jul 30 10:21:10 2001
Return-Path: <steve@mail.yahoo.com>
Received: from blueyonder.co.uk (pcow035o.blueyonder.co.uk [195.188.53.121])
	by hub.freebsd.org (Postfix) with ESMTP id 47D4A37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 30 Jul 2001 10:21:10 -0700 (PDT)
	(envelope-from steve@mail.yahoo.com)
Received: from mail.yahoo.com ([62.30.71.240]) by blueyonder.co.uk  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Mon, 30 Jul 2001 18:21:13 +0100
Received: (from steve@localhost)
	by mail.yahoo.com (8.11.3/8.11.3) id f6UHCkL08943;
	Mon, 30 Jul 2001 18:12:46 +0100 (BST)
	(envelope-from steve)
Message-Id: <200107301712.f6UHCkL08943@mail.yahoo.com>
Date: Mon, 30 Jul 2001 18:12:46 +0100 (BST)
From: Steve Roome <steve@semtexforsale.co.uk>
Reply-To: steve@semtexforsale.co.uk
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: still documented broken options in gcc manpage
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         29331
>Category:       gnu
>Synopsis:       still documented broken options in gcc manpage
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 30 10:30:00 PDT 2001
>Closed-Date:    Mon Oct 14 10:56:42 PDT 2002
>Last-Modified:  Mon Oct 14 10:56:42 PDT 2002
>Originator:     Steve Roome
>Release:        FreeBSD 4.3-RELEASE i386
>Organization:
>Environment:
System: FreeBSD dylan.home 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Fri Jul 20 15:16:40 BST 2001 steve@dylan.home:/usr/src/sys/compile/PEPCROSS i386

>Description:

gcc still has -mno-move option documented in the manpage but if you
view the GCC GNATS database (PR optimization/496) you'll see that it
should not still be documented as it's apparently not a working
option. Beside the manpage doesn't explain what it does anyway.

Until the gcc folks get around to fixing their compiler to not accept
broken options should we remove the offending -mno-move option from
the manpage (a small patch to the 4.3-RELEASE manpage is supplied)

>How-To-Repeat:
	man gcc

>Fix:

Here's a patch to the gcc.1 manpage (it's a patch against 
an uncompressed /usr/share/man/en.ISO_8859-1/man1/gcc.1.gz)

--- gcc.1       Mon Jul 30 18:07:18 2001
+++ gcc.1.orig  Mon Jul 30 18:06:14 2001
@@ -463,6 +463,7 @@
 \-mfancy\-math\-387
 \-mno\-wide\-multiply
 \-mdebug\-addr
+\-mno\-move
 \-mprofiler\-epilogue
 \-reg\-alloc=LIST
 .Sp
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->obrien 
Responsible-Changed-By: asmodai 
Responsible-Changed-When: Tue Jul 31 09:21:44 PDT 2001 
Responsible-Changed-Why:  
David O`Brien is our liaison with the GCC development team. 

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

From: Peter Pentchev <roam@orbitel.bg>
To: Steve Roome <stephen_roome@yahoo.com>
Cc: David O'Brien <obrien@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: gnu/29331: still documented broken options in gcc manpage
Date: Tue, 31 Jul 2001 18:55:12 +0300

 Steve,
 
 Yep, your points seem valid.
 
 I think this should be brought up with David O'Brien, the GCC maintainer
 in FreeBSD.  David, do you think you would have any influence on the GCC
 team on the question of removing the (obviusly dysfunctional) options
 from the GCC code?  If not, what about the GCC in FreeBSD?  Steve seems
 to imply that the two options mentioned (-mno-move and -mno-ieee-fp)
 actually break the resulting code - this would certainly be a bug.
 
 G'luck,
 Peter
 
 -- 
 If there were no counterfactuals, this sentence would not have been paradoxical.
 
 On Tue, Jul 31, 2001 at 04:35:29PM +0100, Steve Roome wrote:
 > Although I agree with you I did raise the GNU GNATS pr
 > optimization/496 (I can't figure out how to link to that), the PR was
 > closed after some time as it was pointed out that -mno-move was not
 > supposed to be a working feature in released code.
 > 
 > They pr I sent to them also pointed out that -mno-ieee-fp caused
 > problems with code as well. However the PR was closed, imho,
 > over-zealously without anyone looking at the issue of documentation,
 > nor, afaict, removing the options from the compiler.
 > 
 > If gcc don't wish to address their pr's properly I suppose that there
 > is nothing we can do at the FreeBSD end, although there are other
 > instances where contrib code (and especially ports) have specific
 > patches in place for FreeBSD due to problems with that code.
 > 
 > IMHO, gcc folks should fix it, but it's a year old problem now, and
 > either we ought to get an import of a newer gcc into -stable or
 > perhaps have a local patch.
 > 
 > I certainly see your point, however both options causes breakage on
 > legal code. This isn't really ideal for a compiler in the base system.
 > Considering that the docs actually mention the flags and that they
 > are legal, again, shouldn't something be done about it, and if not
 > by the gcc people (who often seem incapable of adding minor patches
 > to fix fairly stupid problems) then locally at the FreeBSD end.
 > 
 > 	Steve Roome
 > 
 > 
 > On Tue, Jul 31, 2001 at 05:47:47PM +0300, Peter Pentchev wrote:
 > > On Mon, Jul 30, 2001 at 06:12:46PM +0100, Steve Roome wrote:
 > > > 
 > > > >Number:         29331
 > > > >Category:       gnu
 > > > >Synopsis:       still documented broken options in gcc manpage
 > > > >Originator:     Steve Roome
 > > > >Release:        FreeBSD 4.3-RELEASE i386
 > > > >Organization:
 > > > >Environment:
 > > > System: FreeBSD dylan.home 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Fri Jul 20 15:16:40 BST 2001 steve@dylan.home:/usr/src/sys/compile/PEPCROSS i386
 > > > 
 > > > >Description:
 > > > 
 > > > gcc still has -mno-move option documented in the manpage but if you
 > > > view the GCC GNATS database (PR optimization/496) you'll see that it
 > > > should not still be documented as it's apparently not a working
 > > > option. Beside the manpage doesn't explain what it does anyway.
 > > 
 > > The compiler still supports (or at least accepts) this option, though.
 > > 
 > > [roam@ringworld:v2 ~/c/misc/foo]$ gcc -mno-move foo9.c
 > > [roam@ringworld:v2 ~/c/misc/foo]$
 > > 
 > > > Until the gcc folks get around to fixing their compiler to not accept
 > > > broken options should we remove the offending -mno-move option from
 > > > the manpage (a small patch to the 4.3-RELEASE manpage is supplied)
 > > 
 > > I believe that our gcc(1) manpage is part of the externally maintained
 > > GCC source.  This means, among other things, that there is a major
 > > reason not to introduce local changes to that code - all such changes
 > > cause more problems when importing the next version of the externally
 > > maintained software package.
 > > 
 > > So I believe that the FreeBSD project way would be to not make such
 > > trivial changes until the GCC maintainers decide to obsolete/remove
 > > this option.  Removing it from the manpage would not gain us much,
 > > either: since it is not documented, if no one uses it, no one would
 > > gain anything from not seeing it mentioned; and if there are people
 > > who use it, they would continue using it even if it were not documented,
 > > yet the compiler still accepts it as a valid option.

From: Peter Pentchev <roam@orbitel.bg>
To: Steve Roome <steve@semtexforsale.co.uk>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: gnu/29331: still documented broken options in gcc manpage
Date: Tue, 31 Jul 2001 17:47:47 +0300

 On Mon, Jul 30, 2001 at 06:12:46PM +0100, Steve Roome wrote:
 > 
 > >Number:         29331
 > >Category:       gnu
 > >Synopsis:       still documented broken options in gcc manpage
 > >Originator:     Steve Roome
 > >Release:        FreeBSD 4.3-RELEASE i386
 > >Organization:
 > >Environment:
 > System: FreeBSD dylan.home 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Fri Jul 20 15:16:40 BST 2001 steve@dylan.home:/usr/src/sys/compile/PEPCROSS i386
 > 
 > >Description:
 > 
 > gcc still has -mno-move option documented in the manpage but if you
 > view the GCC GNATS database (PR optimization/496) you'll see that it
 > should not still be documented as it's apparently not a working
 > option. Beside the manpage doesn't explain what it does anyway.
 
 The compiler still supports (or at least accepts) this option, though.
 
 [roam@ringworld:v2 ~/c/misc/foo]$ gcc -mno-move foo9.c
 [roam@ringworld:v2 ~/c/misc/foo]$
 
 > Until the gcc folks get around to fixing their compiler to not accept
 > broken options should we remove the offending -mno-move option from
 > the manpage (a small patch to the 4.3-RELEASE manpage is supplied)
 
 I believe that our gcc(1) manpage is part of the externally maintained
 GCC source.  This means, among other things, that there is a major
 reason not to introduce local changes to that code - all such changes
 cause more problems when importing the next version of the externally
 maintained software package.
 
 So I believe that the FreeBSD project way would be to not make such
 trivial changes until the GCC maintainers decide to obsolete/remove
 this option.  Removing it from the manpage would not gain us much,
 either: since it is not documented, if no one uses it, no one would
 gain anything from not seeing it mentioned; and if there are people
 who use it, they would continue using it even if it were not documented,
 yet the compiler still accepts it as a valid option.
 
 G'luck,
 Peter
 
 -- 
 When you are not looking at it, this sentence is in Spanish.

From: Steve Roome <stephen_roome@yahoo.com>
To: Peter Pentchev <roam@orbitel.bg>
Cc: "David O'Brien" <obrien@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: gnu/29331: still documented broken options in gcc manpage
Date: Wed, 1 Aug 2001 11:50:43 +0100

 On Tue, Jul 31, 2001 at 06:55:12PM +0300, Peter Pentchev wrote:
 > Steve,
 > 
 > Yep, your points seem valid.
 > 
 > I think this should be brought up with David O'Brien, the GCC maintainer
 > in FreeBSD.  David, do you think you would have any influence on the GCC
 > team on the question of removing the (obviusly dysfunctional) options
 > from the GCC code?  If not, what about the GCC in FreeBSD?  Steve seems
 > to imply that the two options mentioned (-mno-move and -mno-ieee-fp)
 > actually break the resulting code - this would certainly be a bug.
 
 To be slighly more precise about things, on FreeBSD-4.3-RELEASE
 (with gcc version 2.95.3 [FreeBSD] 20010315 (release))
 
 -mno-move causes this :
 
 gcc -mno-move -mcpu=pentiumpro -c main.c -o main.o -I/usr/X11R6/include
 main.c: In function `ilimit':
 main.c:23: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3883
 Please submit a full bug report.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 *** Error code 1
 
 -mno-ieee-fp problem is exactly as I described in FreeBSD pr : gnu/21026.
 
 However that was gcc v 2.95.2 and it wasn't fixed in 2.95.3 The pr,
 optimization/96, which I submitted to the gnu folks just got closed
 without anyone looking at it by the looks of things. (Someone arrogantly
 assumed I was just pressing buttons I shouldn't have been, that those
 buttons shouldn't be there is obviously not considered a problem!)
 
 It went much like this :
 
 Simple test case of gcc -mno-ieee-fp -march=pentiumpro
 int main() {
   double xv=0.2;
   return (xv>0);
 }
 gives you a:
 gcc: Internal compiler error: program cc1 got fatal signal 11
 
 N.B. I'm *CERTAIN* that this is not a hardware problem sig11 !
 [I started the rewrite of the sig11 faq entry last september, and
 I'm *sure* this is just gcc being naff!]
 
 Don't worry, I'll still be ranting on about this this time next year
 as well I expect. (Unless of course gcc have fixed it in a newer version,
 but I haven't had a chance to try gcc 3.0 yet, perhaps someone else can
 test these under 3.0 and then tell me to shut up as all is well now!)
 
 	Steve "Compiler Hater" Roome
 
 > 
 > G'luck,
 > Peter
 > 
 > -- 
 > If there were no counterfactuals, this sentence would not have been paradoxical.
 > 
 > On Tue, Jul 31, 2001 at 04:35:29PM +0100, Steve Roome wrote:
 > > Although I agree with you I did raise the GNU GNATS pr
 > > optimization/496 (I can't figure out how to link to that), the PR was
 > > closed after some time as it was pointed out that -mno-move was not
 > > supposed to be a working feature in released code.
 > > 
 > > They pr I sent to them also pointed out that -mno-ieee-fp caused
 > > problems with code as well. However the PR was closed, imho,
 > > over-zealously without anyone looking at the issue of documentation,
 > > nor, afaict, removing the options from the compiler.
 > > 
 > > If gcc don't wish to address their pr's properly I suppose that there
 > > is nothing we can do at the FreeBSD end, although there are other
 > > instances where contrib code (and especially ports) have specific
 > > patches in place for FreeBSD due to problems with that code.
 > > 
 > > IMHO, gcc folks should fix it, but it's a year old problem now, and
 > > either we ought to get an import of a newer gcc into -stable or
 > > perhaps have a local patch.
 > > 
 > > I certainly see your point, however both options causes breakage on
 > > legal code. This isn't really ideal for a compiler in the base system.
 > > Considering that the docs actually mention the flags and that they
 > > are legal, again, shouldn't something be done about it, and if not
 > > by the gcc people (who often seem incapable of adding minor patches
 > > to fix fairly stupid problems) then locally at the FreeBSD end.
 > > 
 > > 	Steve Roome
 > > 
 > > 
 > > On Tue, Jul 31, 2001 at 05:47:47PM +0300, Peter Pentchev wrote:
 > > > On Mon, Jul 30, 2001 at 06:12:46PM +0100, Steve Roome wrote:
 > > > > 
 > > > > >Number:         29331
 > > > > >Category:       gnu
 > > > > >Synopsis:       still documented broken options in gcc manpage
 > > > > >Originator:     Steve Roome
 > > > > >Release:        FreeBSD 4.3-RELEASE i386
 > > > > >Organization:
 > > > > >Environment:
 > > > > System: FreeBSD dylan.home 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Fri Jul 20 15:16:40 BST 2001 steve@dylan.home:/usr/src/sys/compile/PEPCROSS i386
 > > > > 
 > > > > >Description:
 > > > > 
 > > > > gcc still has -mno-move option documented in the manpage but if you
 > > > > view the GCC GNATS database (PR optimization/496) you'll see that it
 > > > > should not still be documented as it's apparently not a working
 > > > > option. Beside the manpage doesn't explain what it does anyway.
 > > > 
 > > > The compiler still supports (or at least accepts) this option, though.
 > > > 
 > > > [roam@ringworld:v2 ~/c/misc/foo]$ gcc -mno-move foo9.c
 > > > [roam@ringworld:v2 ~/c/misc/foo]$
 > > > 
 > > > > Until the gcc folks get around to fixing their compiler to not accept
 > > > > broken options should we remove the offending -mno-move option from
 > > > > the manpage (a small patch to the 4.3-RELEASE manpage is supplied)
 > > > 
 > > > I believe that our gcc(1) manpage is part of the externally maintained
 > > > GCC source.  This means, among other things, that there is a major
 > > > reason not to introduce local changes to that code - all such changes
 > > > cause more problems when importing the next version of the externally
 > > > maintained software package.
 > > > 
 > > > So I believe that the FreeBSD project way would be to not make such
 > > > trivial changes until the GCC maintainers decide to obsolete/remove
 > > > this option.  Removing it from the manpage would not gain us much,
 > > > either: since it is not documented, if no one uses it, no one would
 > > > gain anything from not seeing it mentioned; and if there are people
 > > > who use it, they would continue using it even if it were not documented,
 > > > yet the compiler still accepts it as a valid option.
Responsible-Changed-From-To: obrien->freebsd-bugs 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Mon Sep 10 09:34:23 PDT 2001 
Responsible-Changed-Why:  

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=29331 
State-Changed-From-To: open->closed 
State-Changed-By: jhb 
State-Changed-When: Mon Oct 14 10:52:18 PDT 2002 
State-Changed-Why:  
Submitter claims that this problem is now fixed. 

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