Thanks. Done!
On Tue, Jan 24, 2006 at 12:56:51PM -0500, DJ Delorie wrote:
> Ok to apply then?
Yes.
r~
> Close enough. Thanks for testing.
Ok to apply then?
On Mon, Jan 23, 2006 at 10:29:20PM -0500, DJ Delorie wrote:
> Ok, I can't really read ia64 assembler. Before:
Close enough. Thanks for testing.
r~
> The ia64 build is still running, but I expect it would do something
> similar if it doesn't already have an explicit check for that.
Ok, I can't really read ia64 assembler. Before:
.global f01#
.proc f01#
f01:
.prologue
.body
.mmi
addl r15 = @lt
> Write a small test that is supposed to use one of the set-bit insns.
> Verify that it does before and after the patch.
The m68k indeed starts using BFINS with constants in one-bit
bitfields, where it didn't before. It still uses BFINS for larger
bitfields, as before. So, it will still functio
DJ Delorie wrote:
> Why are one-bit bitfields not allowed? I'm trying to support a
> BSET/BCLR pair that *only* support single bit fields, for I/O ports,
> which are always volatile (and thus you have to use insv, as gcc won't
> do a "or #1,port5" if port5 is volatile).
;) Of course, you could
On Fri, Jan 20, 2006 at 04:56:38PM -0500, DJ Delorie wrote:
> If you could suggest a proper testing strategy, I'm willing to test it.
Write a small test that is supposed to use one of the set-bit
insns. Verify that it does before and after the patch.
r~
> m68k and ia64 spring to mind. Both have set-one-bit-in-register
> type instructions. But the point isn't that x86-64 continues to
> build, but that it's still using the right patterns.
If you could suggest a proper testing strategy, I'm willing to test
it.
On Fri, Jan 20, 2006 at 04:44:04PM -0500, DJ Delorie wrote:
> It's been in my x86-64 builds for the last few months. That's the
> "gcc" that gets used for everything else. Are there other platforms
> that are likely to have one-bit insv patterns? (of course, that's the
> question nobody answered
> Have you done any testing on common platforms to see what happens
> when you change this?
It's been in my x86-64 builds for the last few months. That's the
"gcc" that gets used for everything else. Are there other platforms
that are likely to have one-bit insv patterns? (of course, that's th
On Thu, Jan 19, 2006 at 09:56:54PM -0500, DJ Delorie wrote:
> Nobody has said anything about this for the last two weeks. Can we
> remove this restriction now?
Have you done any testing on common platforms to see what
happens when you change this?
r~
Re-revisiting it...
> Revisiting an old thread...
> > 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.
>
> That
Revisiting an old thread...
> 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.
That's a bad reason to put it in the MI
> > 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.
> 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
> - 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
> 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
> 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
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
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
Why are one-bit bitfields not allowed? I'm trying to support a
BSET/BCLR pair that *only* support single bit fields, for I/O ports,
which are always volatile (and thus you have to use insv, as gcc won't
do a "or #1,port5" if port5 is volatile).
if (HAVE_insv
&& GET_MODE (value) != BLKmod
22 matches
Mail list logo
