Bug 29331

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.

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.

Comment 3 Jeroen Ruigrok van der Werven 2001-07-31 17:21:44 UTC

Responsible Changed
From-To: freebsd-bugs->obrien

David O`Brien is our liaison with the GCC development team.

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.

Comment 5 David E. O'Brien 2001-09-10 17:34:23 UTC

Responsible Changed
From-To: obrien->freebsd-bugs

Comment 6 John Baldwin 2002-10-14 18:52:18 UTC

State Changed
From-To: open->closed

Submitter claims that this problem is now fixed.