Re: Running ranlib after installation - okay or not?

2005-09-04 Thread Peter O'Gorman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerald Pfeifer wrote: | We currently perform the following sequence of commands as part of the | installation (-m 444 being the default on current FreeBSD systems). | I can not see where freebsd could be getting a -m 444 from. The libraries are alway

Successfull build of gcc-3.4.4 on hppa2.0w-hp-hpux11.00

2005-09-04 Thread Rainer Emrich
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 3.4.4 Platform: hppa2.0w-hp-hpux11.00 configure flags: - --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as - --with-ld=/usr/ccs/bi

Successfull build of gcc-3.4.4 on mips-sgi-irix6.5

2005-09-04 Thread Rainer Emrich
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 3.4.4 Platform: mips-sgi-irix6.5 configure flags: - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as - --with-ld=/usr/bin/ld --disable-sh

Re: insv vs one-bit fields

2005-09-04 Thread Richard Henderson
On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: > So... why is it illegal to put a constant into a single bit field? Probably because it was more efficient to use some other pattern for some other target. But there's absolutely zero chance you can reliably use a volatile bit field to

Re: insv vs one-bit fields

2005-09-04 Thread Paul Schlie
Richard Henderson writes: > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: > http://gcc.gnu.org/ml/gcc/2005-09/msg00064.html > > So... why is it illegal to put a constant into a single bit field? > > Probably because it was more efficient to use some other pattern > for some other tar

Re: insv vs one-bit fields

2005-09-04 Thread DJ Delorie
> As it would seem that as HW control/I/O registers are often > typically mapped into a processor's data memory address space, > they may be correspondingly addressable via a read/mask/write as > any N bit field may be? In the case of the m32c, it has a *lot* of single-bit I/O ports, and

Re: insv vs one-bit fields

2005-09-04 Thread Paul Schlie
> From: DJ Delorie <[EMAIL PROTECTED]> >> As it would seem that as HW control/I/O registers are often >> typically mapped into a processor's data memory address space, >> they may be correspondingly addressable via a read/mask/write as >> any N bit field may be? > > In the case of the m32c

Re: insv vs one-bit fields

2005-09-04 Thread DJ Delorie
> - so then any valid width bit-field should be considered a > correspondingly valid const and/or volatile bit-field, which may > potentially be more efficiently accessed as a function of a target's > specific ISA? The "insv" pattern *already* does this. It just doesn't support the one-bit-bitfi

Re: insv vs one-bit fields

2005-09-04 Thread Paul Schlie
> From: DJ Delorie <[EMAIL PROTECTED]> >> - so then any valid width bit-field should be considered a >> correspondingly valid const and/or volatile bit-field, which may >> potentially be more efficiently accessed as a function of a target's >> specific ISA? > > The "insv" pattern *already* does th

Re: insv vs one-bit fields

2005-09-04 Thread DJ Delorie
> > The "insv" pattern *already* does this. It just doesn't support the > > one-bit-bitfield case. > > - which was your point of being unnecessarily restrictive? Yes. There's special code in there to disable insv if the bitfield happens to be one bit in size.