Feature Request: sizeof/typeof/offsetof for bit-fields

I'm writing a binding generator and would love a way to get the size, type, and offset of bit fields of an arbitrary struct. To implement, it appears that 'bit_position' in tree.c has the information required. As a stranger to GCC development, what is the process to get such an extension? Daurn.

Re: How to use _Generic with bit-fields

Thanks for the info. What I'll probably do is file a bug and reply to this thread and the other one when I do. On Thu, Feb 25, 2016, 2:50 PM Joseph Myers wrote: > > On Wed, 24 Feb 2016, Wink Saville wrote: > > > Further more things like printing of "big" bit fi

Re: How to use _Generic with bit-fields

On Wed, 24 Feb 2016, Wink Saville wrote: > Further more things like printing of "big" bit fields such as > unsigned long long int b:33 doesn't issue any warnings with -Wall on clang Of course, printing such a bit-field with %llu etc. isn't fully portable even with

Re: How to use _Generic with bit-fields

On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers wrote: > On Wed, 24 Feb 2016, Wink Saville wrote: > >> > (c) nothing defines semantics of conversion of out-of-range values to >> > bit-fields other than treating the width as part of the type (or in the >> > cas

Re: How to use _Generic with bit-fields

On Wed, 24 Feb 2016, Wink Saville wrote: > > (c) nothing defines semantics of conversion of out-of-range values to > > bit-fields other than treating the width as part of the type (or in the > > case of _Bool bit-fields, having the special wording to make it explicit >

Re: How to use _Generic with bit-fields

m sizeof, if you > > > want to be able to apply that to expressions that might be bit-fields) - > > > or any of the other techniques for achieving promotions of selected types. > > > > Unfortunately, the + n trick is far too limited to be generally > > usable.

Re: How to use _Generic with bit-fields

On Wed, 24 Feb 2016, Martin Sebor wrote: > > That can be avoided simply by using unary + in the controlling expression > > of _Generic (just as using unary + will avoid an error from sizeof, if you > > want to be able to apply that to expressions that might be bit-fields) -

Re: How to use _Generic with bit-fields

ociation int i = _Generic (s.i, unsigned: 1); ^ That can be avoided simply by using unary + in the controlling expression of _Generic (just as using unary + will avoid an error from sizeof, if you want to be able to apply that to expressions that might be bit-fields) - or an

Re: How to use _Generic with bit-fields

problem is simply that >> wording that specifies the feature was poorly chosen and GCC seems >> to follow it a bit too strictly, and to the detriment of usability.) > > The wording for bit-fields, although unclear in places, elegantly > addresses all the issues with what the semantic

Re: How to use _Generic with bit-fields

On Mon, 22 Feb 2016, Martin Sebor wrote: > for the C standard not to support it. (The problem is simply that > wording that specifies the feature was poorly chosen and GCC seems > to follow it a bit too strictly, and to the detriment of usability.) The wording for bit-fields, althoug

Re: How to use _Generic with bit-fields

On 02/21/2016 06:44 PM, Wink Saville wrote: I've tried you hack, but it doesn't work with "long bit fields". Also, I've run into another problem. Instead of using unsigned char for the bit field I changed it to a long unsigned int:33 and now I can't print

Re: How to use _Generic with bit-fields

On Mon, 22 Feb 2016, Wink Saville wrote: > I understand "long" bit fields are in ISO, but its a gcc extension so > it would seem it should play nice with as much of the language as > possible. > > It seems the root of the problem here is the length encoding > in th

Re: How to use _Generic with bit-fields

I'm sorry I meant: I understand "long" bit lengths are NOT in ISO, " On Mon, Feb 22, 2016 at 4:06 PM, Wink Saville wrote: > I understand "long" bit fields are in ISO, but its a gcc extension so > it would seem it should play nice with as much of the

Re: How to use _Generic with bit-fields

I understand "long" bit fields are in ISO, but its a gcc extension so it would seem it should play nice with as much of the language as possible. It seems the root of the problem here is the length encoding in the type, why does gcc do that, does the standard require it? On Mon, Feb 2

Re: How to use _Generic with bit-fields

On Mon, 22 Feb 2016, Wink Saville wrote: > What about printing of "long" bit fields? I wonder if there should be an > option which indicates that bit field types should not include their length. "long" bit-fields aren't even guaranteed by ISO C to be supported at

Re: How to use _Generic with bit-fields

I wonder if ISO C really ought to have a new Constraint "The controlling expression of a generic selection shall not be an expression that designates a bit-field member." (so requiring a diagnostic), much like such expressions being disallowed in sizeof, to reflect the special natu

Re: How to use _Generic with bit-fields

I've tried you hack, but it doesn't work with "long bit fields". Also, I've run into another problem. Instead of using unsigned char for the bit field I changed it to a long unsigned int:33 and now I can't print it without a warning. Here is my Makefile: CC = gcc

Re: Manipulating bit fields is behaving inconsistently

On Fri, 19 Feb 2016, Wink Saville wrote: > The two links in msg00156.html point to single emails and the > formatting is odd, such as in 13560.txt: > > i =3D =5FGeneric(st.bf, > > Is there a way to look at the actual email thread using a browser or > some other means? I'm not aware of any WG1

Re: How to use _Generic with bit-fields

On Fri, 19 Feb 2016, Wink Saville wrote: > And I've tried to use _Generic to print the type of a bit field but > the compiler fails with: Indeed, bit-field types cannot match any type name, only default. The only conversions applied to the controlling expression are those involved in lvalue to

Re: How to use _Generic with bit-fields

On 02/19/2016 11:25 AM, Wink Saville wrote: I'm using gcc 5.3.0: $ gcc --version gcc (GCC) 5.3.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

Re: Manipulating bit fields is behaving inconsistently

The two links in msg00156.html point to single emails and the formatting is odd, such as in 13560.txt: i =3D =5FGeneric(st.bf, Is there a way to look at the actual email thread using a browser or some other means? On Fri, Feb 19, 2016 at 9:30 AM, Joseph Myers wrote: > See the references I ga

How to use _Generic with bit-fields

I'm using gcc 5.3.0: $ gcc --version gcc (GCC) 5.3.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And I've tried to use _Generic to print th

Re: Manipulating bit fields is behaving inconsistently

See the references I gave in . -- Joseph S. Myers jos...@codesourcery.com

Re: Manipulating bit fields is behaving inconsistently

On Fri, Feb 19, 2016 at 12:43 PM, Wink Saville wrote: > What is the process for a patch with a new option to allow a different > behavior? Write one (with testcases), test it and then post it here for review. Richard.

Re: Manipulating bit fields is behaving inconsistently

What is the process for a patch with a new option to allow a different behavior?

Re: Manipulating bit fields is behaving inconsistently

On Fri, Feb 19, 2016 at 12:14 PM, Wink Saville wrote: > Can you point me to previous discussions, or maybe some search terms? I'm > curious about the rationale for the odd behavior. I don't remember discussions about a specific decision how to implement the GCC extension but I remember when fixin

Re: Manipulating bit fields is behaving inconsistently

On Thu, Feb 18, 2016 at 5:31 PM, Wink Saville wrote: > You've convinced me that this isn't a bug, but I assume you'd agree > its weird at best. I tested it with clang and it works as I'd expect: > > $ make > clang -x c -m64 -O3 -Wall -o test.o -c test.c > objdump -d test.o > test.txt > clang -m64

Re: Manipulating bit fields is behaving inconsistently

You've convinced me that this isn't a bug, but I assume you'd agree its weird at best. I tested it with clang and it works as I'd expect: $ make clang -x c -m64 -O3 -Wall -o test.o -c test.c objdump -d test.o > test.txt clang -m64 -O3 -Wall test.o -o test wink@wink-desktop:~/prgs/large_fields_are_

Re: Manipulating bit fields is behaving inconsistently

Hi, > struct fields { > long long unsigned f0:12; > long long unsigned f1:52; > } __attribute__((__packed__)); the C99 standard ISO/IEC 9899 forbids this type: 6.7.2.1 Structure and union specifiers 4 A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed

Manipulating bit fields is behaving inconsistently

When I shift a bit field in an expression small bit fields behave one way and large bit fields another. I'm using gcc 5.3.0 on Arch Linux: $ gcc --version gcc (GCC) 5.3.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There

Re: Do BLKmode bit-fields still exist?

On Fri, Nov 6, 2009 at 10:46 AM, Eric Botcazou wrote: >> In a desparate try to get some testcases which do have BLKmode bit-fields >> I bootstrapped and regtested the below patch (as part of a larger patch, >> though) on seven architectures with all languages (on two without

Re: Do BLKmode bit-fields still exist?

> In a desparate try to get some testcases which do have BLKmode bit-fields > I bootstrapped and regtested the below patch (as part of a larger patch, > though) on seven architectures with all languages (on two without Ada). Yet it's easy in Ada on platforms with strict alignme

Re: Bit fields

On 08/31/2009 07:20 PM, Jean Christophe Beyler wrote: Ok, is it normal to see a ashift with a negative value though or is this already sign of a (potentially) different problem? I seem to recall that it's normal. Combine was originally written in the days of VAX, where negative shifts were all

Re: Bit fields

On Mon, Aug 31, 2009 at 5:27 PM, Richard Henderson wrote: > On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote: >> >> I am going to try this but shouldn't it be : >> >> (set (reg:QI new-scratch)) >>       (zero_extract:DI ...)) > > No. Ok, I think I understand why not: >> (insn 9 8 10 3 struct4

Re: Bit fields

On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote: I am going to try this but shouldn't it be : (set (reg:QI new-scratch)) (zero_extract:DI ...)) No. Any ideas? Nope. You'll have to debug it. r~

Re: Bit fields

On Mon, Aug 31, 2009 at 4:36 PM, Richard Henderson wrote: > On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote: >> >> If I replace this : >> (define_insn "extzv" >>   [(set (match_operand 0 "register_operand" "") >>         (zero_extract (match_operand 1 "register_operand" "") >>                

Re: Bit fields

On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote: If I replace this : (define_insn "extzv" [(set (match_operand 0 "register_operand" "") (zero_extract (match_operand 1 "register_operand" "") (match_operand 2 "const_int_operand" "") (ma

Re: Bit fields

Sorry, you are correct. That line is the : gcc_assert (outermode != VOIDmode); of the simplify_subreg function. However, I've played around with it and saw that I made a mistake when writing up this question, I simplified what I had put in my MD file, and actually made a mistake. I apologize. I

Re: Bit fields

Jean Christophe Beyler writes: > But I get this message: > struct4.c: In function 'goo': > struct4.c:32: internal compiler error: in simplify_subreg, at > simplify-rtx.c:4923 > > Does anybody know how can I solve this issue ? You need to start by looking at line 4923 of simplify-rtx.c to see wha

Bit fields

Dear all, I am currently working on handling bit-fields on my port and am having difficulties understanding why GCC is having problems with what I wrote in. Following what mips did: (define_expand "extzv" [(set (match_operand 0 "register_operand") (zero_extr

Re: Problem with init of structure bit fields

And that problem was visible in both 8 and 16 bits configurations. So I suspect the problem won't be seen on PowerPC unless someone does TI or OI bit fields... -- Stelian Pop

Re: Problem with init of structure bit fields

Stelian Pop writes: > On Wed, Jun 03, 2009 at 07:49:29PM +0200, Stelian Pop wrote: > >> I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble >> when initializing the bit fields of a structure. > > Ok, after further analysis, it loo

Re: Problem with init of structure bit fields

On Wed, Jun 03, 2009 at 07:49:29PM +0200, Stelian Pop wrote: > I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble > when initializing the bit fields of a structure. Ok, after further analysis, it looks like a genuine bug in gcc, in store_bit_field_1():

Problem with init of structure bit fields

Hi, I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble when initializing the bit fields of a structure. The testcase is based on a modified gcc torture testcase, the natural registers are 16 bits, and long long is defined to be 64 bit wide: struct itmp {

Re: Facing problem with bit fields, when i am compiling my code with GCC.

On 4/5/06, Devendra Mulakkayala <[EMAIL PROTECTED]> wrote: > 2. I know that these bit fields are compiler dependent. Is there any option > in GCC to set the bit fields from top to bottom ( MSB to LSB ) > in structure. > 3. As per the client requirement we are not supposed to

Facing problem with bit fields, when i am compiling my code with GCC.

Hello, ISSUE: Facing problem with bit fields, when i am compiling my code with GCC. It was previously compiled with diab compiler and was working fine. In our code Union definition is as follows..., union { unsigned_8 indicator; struct { unsigned_8 unused : 6; unsigned_8 speed :1; unsigned_8

Re: insv vs one-bit fields

Thanks. Done!

Re: insv vs one-bit fields

On Tue, Jan 24, 2006 at 12:56:51PM -0500, DJ Delorie wrote: > Ok to apply then? Yes. r~

Re: insv vs one-bit fields

> Close enough. Thanks for testing. Ok to apply then?

Re: insv vs one-bit fields

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~

Re: insv vs one-bit fields

> 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

Re: insv vs one-bit fields

> 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

RE: insv vs one-bit fields

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 volat

Re: insv vs one-bit fields

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~

Re: insv vs one-bit fields

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

Re: insv vs one-bit fields

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

Re: insv vs one-bit fields

> 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

Re: insv vs one-bit fields

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: insv vs one-bit fields

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

Re: insv vs one-bit fields

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

Re: insv vs one-bit fields

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

Re: insv vs one-bit fields

> 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

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

> 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

> 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

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? Candidly the only potential problem I see may occur if multiple independent volatile bit fields of any size are defined within

Re: insv vs one-bit fields

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

insv vs one-bit fields

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

Re: Offset and Bit Mask for Bit Fields?

Andrew Haley wrote: Dimitry Golubovsky writes: > > If one wants to automatically determine offset of a regular field in a > C structure, one uses `offsetof' > > According to the documentation, > > == > This macro (offsetof) won't work if member is a bit field; you get an > erro

Re: Offset and Bit Mask for Bit Fields?

ld; you get an > error from the C compiler in that case. > == Yes, because it's not addressable. > Do there exist any means in gcc to measure offsets (of enclosing > integer field) and bit mask for bit fields? No. > If not, any chance to add them in the future?

Offset and Bit Mask for Bit Fields?

Do there exist any means in gcc to measure offsets (of enclosing integer field) and bit mask for bit fields? If not, any chance to add them in the future? -- Dimitry Golubovsky Anywhere on the Web