Re: Clarification required about bitfields

See the WG14 reflector thread starting with , and the reference back to the analysis of the textual history in . Effectively, you can treat choices in this area as being implementation-defined or unspec

Re: Clarification required about bitfields

On December 23, 2015 9:28:32 AM GMT+01:00, Konstantin Vladimirov wrote: >Hi, > >Now LLVM and GCC essentially disagrees on simple test (minimized from >one of dejagnu tests): > >#include > >struct s { > unsigned long long u33: 33; > unsigned long long u40: 40; > unsigned long long u41: 41; >};

Clarification required about bitfields

Hi, Now LLVM and GCC essentially disagrees on simple test (minimized from one of dejagnu tests): #include struct s { unsigned long long u33: 33; unsigned long long u40: 40; unsigned long long u41: 41; }; struct s a = { 0x10, 0x10, 0x10 }; int main (void) { if (a.u33 * a.u3

RE: Still fails with strict-volatile-bitfields

Hi, On Mon, 13 Jan 2014 10:26:03, Joey Ye wrote: > > Bernd, > > If that's the case, can you please firstly fix invoke.texi where the > behavior of strict-volatile-bitfields is described? At least my > interpretation of current doc doesn't explain the behavior of

Re: Still fails with strict-volatile-bitfields

Bernd, If that's the case, can you please firstly fix invoke.texi where the behavior of strict-volatile-bitfields is described? At least my interpretation of current doc doesn't explain the behavior of the case we are discussing. Also it should be a generic definition rather than targe

RE: Still fails with strict-volatile-bitfields

our without such warnings. >>>>> >>>>> R. >>>> >>>> No. This example was working in 4.6 and broken in 4.7 and 4.8. >>>> Well, 4.7 should have warned about that. >>>> >>>> 4.9 does simply not change that, beca

Re: Still fails with strict-volatile-bitfields

warnings. >>>>> >>>>> R. >>>> >>>> No. This example was working in 4.6 and broken in 4.7 and 4.8. >>>> Well, 4.7 should have warned about that. >>>> >>>> 4.9 does simply not change that, because it would viola

Re: Still fails with strict-volatile-bitfields

ve warned about that. >>> >>> 4.9 does simply not change that, because it would violate the C++ >>> memory model. Maybe that should go into release notes. >> >> That's no excuse for not generating a warning at compile time when the >> situation is enco

RE: Still fails with strict-volatile-bitfields

excuse for not generating a warning at compile time when the > situation is encountered. Users of this feature are experiencing a > quiet change of behaviour and that's unacceptable, even if the compiler > is doing what it was intended to do; that doesn't necessarily match the

Re: Still fails with strict-volatile-bitfields

the C++ > memory model. Maybe that should go into release notes. That's no excuse for not generating a warning at compile time when the situation is encountered. Users of this feature are experiencing a quiet change of behaviour and that's unacceptable, even if the compiler is doing w

Re: Still fails with strict-volatile-bitfields

> No. This example was working in 4.6 and broken in 4.7 and 4.8. Note that it probably broke in 4.7.1 because the DECL_BIT_FIELD_REPRESENTATIVE stuff was backported after the initial 4.7.0 release. -- Eric Botcazou

Re: Still fails with strict-volatile-bitfields

> No. This example was working in 4.6 and broken in 4.7 and 4.8. > Well, 4.7 should have warned about that. The 4.7 branch is not closed so it's not too late to add the warning there. -- Eric Botcazou

RE: Still fails with strict-volatile-bitfields

(!), (writing not all bits, and using unaligned accesses) and that is fixed in 4.9. Bernd. > >> You can get the expected code, by changing the struct >> like this: >> >> struct str { >> volatile unsigned f1: 8; >> unsigned dummy:24; >> }; >> >> If

Re: Still fails with strict-volatile-bitfields

ntial that we don't have quiet changes in behaviour without such warnings. R. > You can get the expected code, by changing the struct > like this: > > struct str { > volatile unsigned f1: 8; > unsigned dummy:24; > }; > > If it is written this way the C++ memory

RE: Still fails with strict-volatile-bitfields

s a major case where the C++ memory model is in conflict with AAPCS. You can get the expected code, by changing the struct like this: struct str { volatile unsigned f1: 8; unsigned dummy:24; }; If it is written this way the C++ memory model allows QImode, HImode, SImode. And -fstrict-volati

Still fails with strict-volatile-bitfields

Sandra, Bernd, Can you take a look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734 It seems a siimple case still doesn't work as expected. Did I miss anything? Thanks, Joey

Re: integer_onep vs. signed 1-bit bitfields

On Sat, 2 Nov 2013, Marc Glisse wrote: > On Sat, 2 Nov 2013, Jakub Jelinek wrote: > > > On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote: > > > OK, thanks. I should have realised this earlier, but we have: > > > > > > /* Return 1 if EXPR is the integer constant one or the corre

Re: integer_onep vs. signed 1-bit bitfields

On Sat, 2 Nov 2013, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote: > >> What should integer_onep mean if we have a signed 1-bit bitfield in > >> which the bit is set? Seen as a 1-bit value it's "obviously" 1, > >> but seen

Re: integer_onep vs. signed 1-bit bitfields

On Sat, 2 Nov 2013, Jakub Jelinek wrote: On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote: OK, thanks. I should have realised this earlier, but we have: /* Return 1 if EXPR is the integer constant one or the corresponding complex constant. */ int integer_onep (const_tree

Re: integer_onep vs. signed 1-bit bitfields

On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote: > OK, thanks. I should have realised this earlier, but we have: > > /* Return 1 if EXPR is the integer constant one or the corresponding >complex constant. */ > > int > integer_onep (const_tree expr) > ... > /* Return 1 if E

Re: integer_onep vs. signed 1-bit bitfields

Jakub Jelinek writes: > On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote: >> What should integer_onep mean if we have a signed 1-bit bitfield in >> which the bit is set? Seen as a 1-bit value it's "obviously" 1, >> but seen as a value extended to infinite precision it's -1. >> >

Re: integer_onep vs. signed 1-bit bitfields

On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote: > What should integer_onep mean if we have a signed 1-bit bitfield in > which the bit is set? Seen as a 1-bit value it's "obviously" 1, > but seen as a value extended to infinite precision it's -1. > > Current mainline returns fal

integer_onep vs. signed 1-bit bitfields

What should integer_onep mean if we have a signed 1-bit bitfield in which the bit is set? Seen as a 1-bit value it's "obviously" 1, but seen as a value extended to infinite precision it's -1. Current mainline returns false while wide-int returns true. This came up in gcc.c-torture/execute/930718

Continue strict-volatile-bitfields fixes

-fstrict-volatile-bitfields doesn't work incorrectly in some cases when storing into a volatile bit-field. Bernd provided a fix here about 1 year ago: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html. But it is pending to trunk. Here are my humble opinions and hopefully we can revi

Re: adjacent bitfields optimization

gt;  s1.f2 = s2.f2; >> } >> >> we get (x86_64 target): >> >>  movzbl  s2(%rip), %edx >>  movzbl  s1(%rip), %eax >>  movl    %edx, %ecx >>  andl    $-4, %eax >>  andl    $2, %edx >>  andl    $1, %ecx >>  orl %ecx, %eax >>  or

Re: adjacent bitfields optimization

> s1.f1 = s2.f1; > s1.f2 = s2.f2; > } > > we get (x86_64 target): > > movzbl  s2(%rip), %edx > movzbl  s1(%rip), %eax > movl    %edx, %ecx > andl    $-4, %eax > andl    $2, %edx > andl    $1, %ecx > orl %ecx, %eax > orl %edx, %eax &g

Re: adjacent bitfields optimization

%edx, %eax > movb    %al, s1(%rip) > ret > > > Could gcc optimize two or more operations in adjacent bitfields into one > operation ? This question looks more appropriate for the mailing list gcc-h...@gcc.gnu.org rather than the mailing list gcc@gcc.gnu.org. I agree that this looks

adjacent bitfields optimization

), %eax movl    %edx, %ecx andl    $-4, %eax andl    $2, %edx andl    $1, %ecx orl %ecx, %eax orl %edx, %eax movb    %al, s1(%rip) ret Could gcc optimize two or more operations in adjacent bitfields into one operation ? regards, Alex R. Prado

Re: Bitfields problem

ption file, I currently > worked on the bitfields again to try to get a good code generation > working. Right now, I've followed what was done in the ia64 for signed > extractions : > > (define_insn "extv" >  [(set (match_operand:DI 0 "gr_register_operand&quo

Bitfields problem

As I continue my work on the machine description file, I currently worked on the bitfields again to try to get a good code generation working. Right now, I've followed what was done in the ia64 for signed extractions : (define_insn "extv" [(set (match_operand:DI 0 "gr_r

Re: Bitfields

"Joseph S. Myers" writes: > It has been proposed (and not rejected, but not yet implemented) I'm still working on it...

Re: Bitfields

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 impl

Re: Bitfields

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 specificati

Re: Bitfields

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

Re: Bitfields

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

Bitfields

I wonder if there would be at least a theoretical support by the developers to a proposal for volatile bitfields: When a HW register (thus most likely declared as volatile) is defined as a bitfield, as far as I know gcc treats each bitfield assignment as a separate read-modify-write operation

Re: bitfields: types vs modes?

> 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

Re: bitfields: types vs modes?

> 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

Re: bitfields: types vs modes?

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

Re: bitfields: types vs modes?

> >> 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

Re: bitfields: types vs modes?

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

Re: bitfields: types vs modes?

> 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.

Re: bitfields: types vs modes?

y specifies something about volatile > bitfields, I think we ought to implement that. Yes, we should. I am aware of real user demand for this feature as well. It's a competitive disadvantage for GCC not to have this feature. > I continue to think that a sane programmer would use a di

Re: bitfields: types vs modes?

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 bitfields, I think we ought to implement that. I continue to think that a sane programmer would use a different mechanism. C/

Re: bitfields: types vs modes?

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

Re: bitfields: types vs modes?

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

Re: bitfields: types vs modes?

> 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

Re: bitfields: types vs modes?

tion: just don't use a bitfield. In part, because of the ARM ABI issue, I think we ought to accept patches that fix this problem. It's true that GCC doesn't in general document these semantics, but users of some ABIs have expectations about how volatile bitfields will work. DJ, I

Re: bitfields: types vs modes?

p 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. >> >> However, gcc has a very simplistic heur

Re: bitfields: types vs modes?

int b:25; } t2; t1.a will be accessed as a byte regardless of the target's preferences, whereas t2.c follows the target preferences. > One of our customers has a chip with memory-mapped peripheral > registers that need to be accessed in a specific mode. The registers > represent bi

Re: bitfields: types vs modes?

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:Q

Re: bitfields: types vs modes?

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

Re: bitfields: types vs modes?

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 represe

Re: bitfields: types vs modes?

> 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

Re: bitfields: types vs modes?

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

bitfields: types vs modes?

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. However, gcc has a very simplistic heuristic for deciding

#pragma pack vs. zero-width bitfields

PR 22275 is about a change in the structure layout used by GCC when #pragma pack is mixed with zero-width bitfields. In particular, in GCC 3.3 and earlier, zero-width bitfields still forced the next element to be placed on an alignment boundary, just as they do in unpacked structures. In GCC 3.4

Re: RFC: ms bitfields of aligned basetypes

A testcase to trigger the assert was: typedef _Bool Tal16bool __attribute__ ((aligned (16))); struct S49 { Tal16bool a:1; }; and it turns out that the underlying problem is actually in the general-purpose field layout code. Both known_align and actual_align are calculated as BIGGEST_ALIGNMENT if

Re: RFC: ms bitfields of aligned basetypes

Danny Smith wrote: Jim Wilson wrote http://gcc.gnu.org/ml/gcc/2005-04/msg01172.html Joern RENNECKE wrote: required for Tal16bool. Should we enforce that any storage element allocated for a run of ms-bitfields get the full alignment of the basetype, even when it exceeds

Re: RFC: ms bitfields of aligned basetypes

Joern RENNECKE wrote: required for Tal16bool. Should we enforce that any storage element allocated for a run of ms-bitfields get the full alignment of the basetype, even when it exceeds the size of the basetype and of BIGGEST_ALIGNMENT? Obviously, we should do the exact same thing that the

RFC: ms bitfields of aligned basetypes

a run of ms-bitfields get the full alignment of the basetype, even when it exceeds the size of the basetype and of BIGGEST_ALIGNMENT?