home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.3b1
- Path: sparky!uunet!sun-barr!ames!pacbell.com!tandem!zorch!hico2!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
- From: bruce@blilly.UUCP (Bruce Lilly)
- Subject: Re: problems with some files on osu-cis (and gcc 1.40 bug)
- References: <1992Aug26.151626.10758@sonyd1.Broadcast.Sony.COM> <1992Aug28.010033.13663@ceilidh.beartrack.com> <1992Aug28.181132.11130@cco.caltech.edu>
- Organization: Bruce Lilly
- Date: Mon, 31 Aug 92 23:28:58 GMT
- Message-ID: <1992Aug31.232858.1963@blilly.UUCP>
- Lines: 120
-
- In article <1992Aug28.181132.11130@cco.caltech.edu> andy@cs.caltech.edu (Andy Fyfe) wrote:
- >In article <1992Aug28.010033.13663@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
- >>In article <1992Aug26.151626.10758@sonyd1.Broadcast.Sony.COM> bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) writes:
- >>>Some of the files on osu-cis seem to have been mangled.
- >>>Specifically, in ~/att7300/csvax
- >>> perl-bin.tar.Z
- >>> perl-man.tar.Z
- >>> gnutar.Z
- >>
- >> This sounds like the kind of behavior I have seen when I have
- >>forgotten to set the binary mode on ftp before the transfer.
- >
- >The copy of these files on uunet/OSU is bad. Perhaps the "binary" option
- >was left off when the files were copied from ftp.cs.caltech.edu (in which
- >case all of the files in the csvax subdirectory are probably bad).
-
- Some others seem to be OK (e.g. groff-bin.tar.Z, gcc2-bin.tar.Z).
-
- > Unfortunately,
- >there is no anonymous uucp access to the Caltech machine.
-
- Any plans to change that? Is there anonymous uucp access to a machine
- that has the ftp'able files [NR]FS-mounted?
-
- By the way, there's a bug in the 3b1 version of gcc 1.40.
- Below is the bug report which I sent:
-
- ----------------------------------------------------------------
- To: bug-gcc@prep.ai.mit.edu
- Reply-To: lilb@sony.compuserve.com
- Subject: bug in gcc version 1.40 for mc68k
-
- Consider the following simple program which returns the position of the first '1'
- bit in an integer (in this case should return 2).
-
- int main()
- {
- register int x = 4;
- int i;
-
- for(i=0; i<8 && ((x&1) == 0); x >>= 1, i++)
- ;
- return(i);
- }
-
- When compiled by "gcc -v -O -S gcctest.c", the following results:
- gcc version 1.40
- /usr/local/lib/gcc-cpp -v -undef -D__GNUC__ -Dmc68k -Dunix -Dunixpc -D__mc68k__ -D__unix__ -D__unixpc__ -D__OPTIMIZE__ gcctest.c /usr/tmp/cca24532.cpp
- GNU CPP version 1.40
- /usr/local/lib/gcc-cc1 /usr/tmp/cca24532.cpp -quiet -dumpbase gcctest.c -O -version -o gcctest.s
- GNU C version 1.40 (68k, AT&T UnixPC/gas) compiled by GNU C version 1.40.
- default target switches:
- .file "gcctest.c"
- gcc_compiled.:
- .text
- .even
- .globl _main
- _main:
- link a6,#0
- movel d2,sp@-
- moveq #4,d1
- moveq #0,d0
- L5:
- btst #0,d1
- jne L3
- asrl #1,d1
- addql #1,d0
- moveq #7,d2
- cmpl d0,d2
- jge L5
- L3:
- movel a6@(-4),d2
- unlk a6
- rts
-
- This works as expected (return value 2). However, when the -fstrength-reduce flag is added, we get:
- gcc version 1.40
- /usr/local/lib/gcc-cpp -v -undef -D__GNUC__ -Dmc68k -Dunix -Dunixpc -D__mc68k__ -D__unix__ -D__unixpc__ -D__OPTIMIZE__ gcctest.c /usr/tmp/cca24537.cpp
- GNU CPP version 1.40
- /usr/local/lib/gcc-cc1 /usr/tmp/cca24537.cpp -quiet -dumpbase gcctest.c -fstrength-reduce -O -version -o gcctest.s
- GNU C version 1.40 (68k, AT&T UnixPC/gas) compiled by GNU C version 1.40.
- default target switches:
- .file "gcctest.c"
- gcc_compiled.:
- .text
- .even
- .globl _main
- _main:
- link a6,#0
- moveq #4,d1
- moveq #7,d0
- L5:
- btst #0,d1
- jne L3
- asrl #1,d1
- dbra d0,L5
- clrw d0
- subql #1,d0
- jcc L5
- moveq #8,d0
- L3:
- unlk a6
- rts
-
- This does not work properly (it returns 5, rather than 2).
-
- Other compilation options (e.g. -fcombine-regs) do not appear to alter this behavior.
- I've not had any other problems with -fstrength-reduce, but it clearly causes major
- problems with the above code fragment (simplified from a real program).
- ----------------------------------------------------------------
-
- I was informed that this bug will be fixed in version 1.41, "to
- be released soon". I asked if that meant that there would be
- parallel releases in 1.xx and 2.xx, but received no response.
-
- Andy, do you know if version 2 has the same bug, and do you plan
- to make a binary of 1.41 available after its release?
- --
- Bruce Lilly blilly!bruce@Broadcast.Sony.COM
- ...uunet!sonyusa!sonyd1!blilly!bruce
-