Interestingly enough, if I do this instead:
typedef struct sTest {
int a:12;
int b:20;
int c:7;
int d:15;
}STest;
int64_t bar2 (STest *a)
{
int64_t res = a->b;
return res;
}
I get at the expand pass :
(insn 6 5 7 3 struct3.c:27 (set (reg:SI 75)
(mem/s:SI (reg/v/
"Joseph S. Myers" writes:
> It has been proposed (and not rejected, but not yet implemented)
I'm still working on it...
On Sun, 20 Sep 2009, Joseph S. Myers wrote:
> On Sun, 20 Sep 2009, Zolt??n K??csi wrote:
>
> > I wonder if there would be at least a theoretical support by the
> > developers to a proposal for volatile bitfields:
>
> It has been proposed (and not rejected, but not yet implemented) that
> volatile
On Sun, 20 Sep 2009, Zolt??n K??csi wrote:
> I wonder if there would be at least a theoretical support by the
> developers to a proposal for volatile bitfields:
It has been proposed (and not rejected, but not yet implemented) that
volatile bit-fields should follow the ARM EABI specification (on
Paolo Bonzini wrote:
Is it a completely brain-dead idea?
If I understood it correctly, it would not be standard compliant.
But it's an extension, so I don't see that is an issue of itself.
Paolo
reg.field1 = val1, reg.field2 = val2;
would then turn into fetch, mask with a combined mask of field1 and
field2, or val1, or val2, store.
You can also do the RMW yourself: declare the register volatile, but not
the fields of it, and copy in/out of the register manually.
volatile struct re
> At the risk of being naive: implement it. I'm not quite sure what
> you're looking for here?
Ok, time to ask for a hint. I started at get_best_mode(), adding a
TREE argument for the type, and worked my way out, adding arguments to
functions as needed to propogate the type information. It's g
> At the risk of being naive: implement it. I'm not quite sure what
> you're looking for here?
I'd rather have some confidence that the way I choose to implement it
would be acceptable to those who would be reviewing it ;-)
I'll give it a shot at the same point in the code where we call the
tar
DJ Delorie wrote:
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
> I finally got the last of the feedback I needed from our customers,
> and they agree that the AAPCS functionality is suitable for their
> ports as well.
Great!
> What's
> >> I think the ARM specification is pretty sensible, and would make a
> >> good cross-platform approach.
> >
> > Could you distill it for us?
>
> The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
I finally got the last of the feedback I needed from our customers,
and they agree
DJ Delorie wrote:
>> I think the ARM specification is pretty sensible, and would make a
>> good cross-platform approach.
>
> Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
The term "container" here means the declared type of the bit-field.
(There's
> I think the ARM specification is pretty sensible, and would make a
> good cross-platform approach.
Could you distill it for us? If it's acceptable to my two customers,
it would be a good starting point to define an API for the targets.
Ian Lance Taylor wrote:
>> 1. If the functionality will be allowed in gcc at all
>>
>> 2. What info the target needs to be provided to make the choices it wants
>>
>> 3. What, if any, common code can be shared between the CPUs
>
> Since the ARM ABI apparently specifies something about volatile
>
DJ Delorie writes:
> We seem to have dropped this discussion. I now have *two* customers
> asking for this functionality. Can we pick it up again? We need to
> decide:
>
> 1. If the functionality will be allowed in gcc at all
>
> 2. What info the target needs to be provided to make the choices
We seem to have dropped this discussion. I now have *two* customers
asking for this functionality. Can we pick it up again? We need to
decide:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any, comm
DJ Delorie wrote:
> Yes, that's pretty much what they asked for. However, it is still
> somewhat ambiguous - for example, if you have an 8-bit "int" field,
> which 4 bytes are read to get that field?
I haven't gone back just now to try to find the right words in the ABI,
so I don't know for sur
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf
>
> and, in particular, \S 7.1.7.5, entitled "Volatile bit-fields".
>
> A first question is if these are the semantics that you're looking for
> in your project. If so, then we could collaborate with you on
> impleme
Ian Lance Taylor wrote:
>> So... can I/we move forward on this? Or will such a change be
>> rejected?
> It's hard for me to get excited about something like this. It's
> straightforward a programmer to write code that is clearly correct in
> this sort of situation: just don't use a bitfield.
DJ Delorie writes:
> So... can I/we move forward on this? Or will such a change be
> rejected?
>
> BTW, Since sending this I discovered that gcc treats these
> differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
>
> volatile struct
> {
> unsigned int a:8;
> unsigned int b:24;
> } t1;
>
> volati
So... can I/we move forward on this? Or will such a change be
rejected?
BTW, Since sending this I discovered that gcc treats these
differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
volatile struct
{
unsigned int a:8;
unsigned int b:24;
} t1;
volatile struct
{
unsigned int a:7;
unsigned
On Wed, 11 Mar 2009, Paul Brook wrote:
> PR23623 (I suspect the status on that bug is incorrect, it's nt actually
> fixed). The ARM EABI defines semantics for volatile bitfields, and gcc gets
> this wrong.
If the ARM EABI really documents the semantics for that,
implement-c.texi:Qualifiers does ne
On Wed, 2009-03-11 at 01:05 -0400, DJ Delorie wrote:
> > Can you provide example code? I'm confused enough to believe
> > that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
> > (modulo current bugs).
>
> Imagine a device with four 8-bit registers followed by a 32-bit
> register with
On Tuesday 10 March 2009, DJ Delorie wrote:
> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode. The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
>
> Comm
> Can you provide example code? I'm confused enough to believe
> that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
> (modulo current bugs).
Imagine a device with four 8-bit registers followed by a 32-bit
register with an 8-bit field:
bytestatus (read-only, clears after readin
On Tue, 10 Mar 2009, DJ Delorie wrote:
> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode. The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
Thank you fo
25 matches
Mail list logo
