lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (12/17/87)
Here are some possible bugs in 1.13 gcc. At line 1208 of combine.c there is: || constop & ~ GET_MODE_MASK (GET_MODE (to)) == 0)) It looks like it ought to be: || (constop & ~ GET_MODE_MASK (GET_MODE (to))) == 0)) but I can't be certain. At line 2664 of parse.tab.c there is: if (shorts[7] | shorts[6] | shorts[5] | shorts[4]) which (isn't really a bug but) would be better written with || instead of |. -- Larry Cipriani AT&T Network Systems at cbosgd!osu-cis!tut!lvc Ohio State University
geoff@desint.UUCP (Geoff Kuenning) (12/20/87)
In article <3299@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: > Here are some possible bugs in 1.13 gcc. > if (shorts[7] | shorts[6] | shorts[5] | shorts[4]) > > which (isn't really a bug but) would be better written with || > instead of |. Untrue. The choice of the optimal operator depends on both the CPU architecture and the actual data values. On most CPU's (actually, on every one I've worked on that had booleans at all) using || will make the code take more space, and it will be slower if the first nonzero value is in shorts[5] or shorts[4] (on many machines, it will also be slower if only shorts[7] is zero). -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (12/24/87)
X-Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 Only bugs reported to the address: bug-gcc@prep.ai.mit.edu are reviewed by rms. He does not read USENET netnews. enjoy -len