On 09/02/2011 10:38 AM, Richard Guenther wrote:
On Fri, Sep 2, 2011 at 4:10 PM, Jason Merrill wrote:
I wonder what would break if C++ just set TYPE_SIZE to the as-base size?
Good question. Probably argument passing, as the as-base size wouldn't
get a proper mode assigned form layout_type the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/02/11 02:48, Richard Guenther wrote:
>
> Note that with all this mess I'll re-iterate some of my initial
> thoughts. 1) why not do this C++ (or C) specific stuff in the
> frontends, maybe at gimplifying/genericization time? That way you
> would
On Fri, Sep 2, 2011 at 4:10 PM, Jason Merrill wrote:
> On 09/02/2011 04:53 AM, Richard Guenther wrote:
>>
>> On Thu, Sep 1, 2011 at 5:19 PM, Jason Merrill wrote:
>>>
>>> I think it would make sense to expose this information to the back end
>>> somehow. A hook would do the trick: call it type_da
On 09/02/2011 04:53 AM, Richard Guenther wrote:
On Thu, Sep 1, 2011 at 5:19 PM, Jason Merrill wrote:
I think it would make sense to expose this information to the back end
somehow. A hook would do the trick: call it type_data_size or type_min_size
or some such, which in the C++ front end would
On Fri, Sep 2, 2011 at 2:49 PM, Aldy Hernandez wrote:
>
>> Note that with all this mess I'll re-iterate some of my initial thoughts.
>> 1) why not do this C++ (or C) specific stuff in the frontends, maybe
>> at gimplifying/genericization time? That way you wouldn't need to
>> worry about middle-e
Note that with all this mess I'll re-iterate some of my initial thoughts.
1) why not do this C++ (or C) specific stuff in the frontends, maybe
at gimplifying/genericization time? That way you wouldn't need to
worry about middle-end features but you could rely solely on what
C/C++ permit. It is
On Thu, Sep 1, 2011 at 5:19 PM, Jason Merrill wrote:
> On 09/01/2011 11:10 AM, Aldy Hernandez wrote:
>>>
>>> Basically you can only touch the size of the CLASSTYPE_AS_BASE variant.
>>> For many classes this will be the same as the size of the class itself.
>>
>> All this code is in the middle end,
On Thu, Sep 1, 2011 at 4:16 PM, Aldy Hernandez wrote:
>
>> My point is, the middle-end infrastructure makes it possible for this
>> case to appear, and it seems to be easy to handle conservatively.
>> There isn't a need to wait for users to run into an ICE or an assert we
>> put
>> there IMHO. If
On 09/01/2011 11:10 AM, Aldy Hernandez wrote:
Basically you can only touch the size of the CLASSTYPE_AS_BASE variant.
For many classes this will be the same as the size of the class itself.
All this code is in the middle end, so we're language agnostic.
What do we need here, a hook to query th
Is there a way of distinguishing this particular variant (possible
tail-packing), or will we have to disallow storing into the record tail
padding altogether? That would seriously suck.
Basically you can only touch the size of the CLASSTYPE_AS_BASE variant.
For many classes this will be the sa
On 09/01/2011 10:52 AM, Aldy Hernandez wrote:
To answer your question, I believe we can't touch past the last field
(into the padding) if the subsequent record will be packed into the
first's padding.
Right.
struct A {
int a : 17;
};
struct B : public A {
char c;
};
So here, if gets pac
[Jason, can you pontificate on tail-padding and the upcoming C++
standard with regards to bitfields?]
so you wasn't convinced about my worries about tail-padding re-use?
To answer your question, I believe we can't touch past the last field
(into the padding) if the subsequent record will be
My point is, the middle-end infrastructure makes it possible for this
case to appear, and it seems to be easy to handle conservatively.
There isn't a need to wait for users to run into an ICE or an assert we put
there IMHO. If I'd be fluent in Ada I'd write you a testcase, but I ain't.
Ughh,
> >> Did you test Ada and enable the C++ memory model? ;)
> >
> > See my earlier comment on Ada. Who would ever use the C++ memory model on
> > Ada?
>
> People interoperating Ada with C++. Our bug triager Zdenek who
> figures out the --param?
Right, that's one example. There are also actually s
On Wed, Aug 31, 2011 at 8:09 PM, Aldy Hernandez wrote:
>
>> Did you test Ada and enable the C++ memory model? ;)
>
> See my earlier comment on Ada. Who would ever use the C++ memory model on
> Ada?
People interoperating Ada with C++. Our bug triager Zdenek who
figures out the --param?
>> Btw,
On Wed, Aug 31, 2011 at 6:53 PM, Aldy Hernandez wrote:
>
Sure. I assume in this case, *bit_offset would be 0, right?
>>>
>>> It would be DECL_FIELD_BIT_OFFSET of that field. Oh, and
>>> *byte_offset would be
>>>
>>> *byte_offset = size_binop (MULT_EXPR, TREE_OPERAND (exp, 2),
>>>
Did you test Ada and enable the C++ memory model? ;)
See my earlier comment on Ada. Who would ever use the C++ memory model
on Ada?
Btw, even if the bitfield we access (and thus the whole region) is at a
constant offset, the field _following_ the bitregion (the one you query
above with ge
Sure. I assume in this case, *bit_offset would be 0, right?
It would be DECL_FIELD_BIT_OFFSET of that field. Oh, and
*byte_offset would be
*byte_offset = size_binop (MULT_EXPR, TREE_OPERAND (exp, 2),
size_int (DECL_OFFSET_ALIGN
(field) / BITS_PER_UNIT)
*bit_offset = (TREE_INT_CST_LOW (DECL_FIELD_OFFSET (fld))
* BITS_PER_UNIT
+ TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET (fld)))
- (TREE_INT_CST_LOW (DECL_FIELD_OFFSET (bitregion_start))
* BITS_PER_UNIT
+ TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET (bitregion_sta
On Wed, Aug 31, 2011 at 9:45 AM, Richard Guenther
wrote:
> On Tue, Aug 30, 2011 at 5:01 PM, Aldy Hernandez wrote:
>> [I'm going to respond to this piece-meal, to make sure I don't drop
>> anything. My apologies for the long thread, but I'm pretty sure it's in
>> everybody's kill file by now.]
>>
On Tue, Aug 30, 2011 at 8:13 PM, Aldy Hernandez wrote:
>
>> Btw, *byte_offset is still not relative to the containing object as
>> documented, but relative to the base object of the exp reference
>> tree (thus, to a in a.i.j.k.l instead of to a.i.j.k). If it were supposed
>> to be relative to a.i
On Tue, Aug 30, 2011 at 6:15 PM, Aldy Hernandez wrote:
>
>> *bit_offset is supposed to be relative to *byte_offset then it should
>> be easy to calculate it without another get_inner_reference.
>
> Since, as you suggested, we will terminate early on variable length offsets,
> we can assume both DE
On Tue, Aug 30, 2011 at 5:01 PM, Aldy Hernandez wrote:
> [I'm going to respond to this piece-meal, to make sure I don't drop
> anything. My apologies for the long thread, but I'm pretty sure it's in
> everybody's kill file by now.]
>
>> + /* Be as conservative as possible on variable offsets. *
Btw, *byte_offset is still not relative to the containing object as
documented, but relative to the base object of the exp reference
tree (thus, to a in a.i.j.k.l instead of to a.i.j.k). If it were supposed
to be relative to a.i.j.k get_inner_reference would be not needed
either. Can you clari
*bit_offset is supposed to be relative to *byte_offset then it should
be easy to calculate it without another get_inner_reference.
Since, as you suggested, we will terminate early on variable length
offsets, we can assume both DECL_FIELD_OFFSET and DECL_FIELD_BIT_OFFSET
will be constants by
[I'm going to respond to this piece-meal, to make sure I don't drop
anything. My apologies for the long thread, but I'm pretty sure it's in
everybody's kill file by now.]
+ /* Be as conservative as possible on variable offsets. */
+ if (TREE_OPERAND (exp, 2)
+&& !host_integerp (TREE_OPERA
On Fri, Aug 26, 2011 at 8:54 PM, Aldy Hernandez wrote:
> This is a "slight" update from the last revision, with your issues addressed
> as I explained in the last email. However, everything turned out to be much
> tricker than I expected (variable length offsets with arrays, bit fields
> spanning
This is a "slight" update from the last revision, with your issues
addressed as I explained in the last email. However, everything turned
out to be much tricker than I expected (variable length offsets with
arrays, bit fields spanning multiple words, surprising padding
gymnastics by GCC, etc e
Some comments.
/* If we have a bit-field with a bitsize> 0... */
if (DECL_BIT_FIELD_TYPE (fld)
&& tree_low_cst (DECL_SIZE (fld), 1)> 0)
I think we can check bitsize != 0, thus
&& !integer_zerop (DECL_SIZE (fld))
Done
/* Short-circuit out if we have the
On Tue, Aug 9, 2011 at 8:39 PM, Aldy Hernandez wrote:
>
>> ok, so now you do this only for the first field in a bitfield group. But
>> you
>> do it for _all_ bitfield groups in a struct, not only for the interesting
>> one.
>>
>> May I suggest to split the loop into two, first searching the first
ok, so now you do this only for the first field in a bitfield group. But you
do it for _all_ bitfield groups in a struct, not only for the interesting one.
May I suggest to split the loop into two, first searching the first field
in the bitfield group that contains fld and then in a separate l
Andrew's mail to gcc-patches keeps bouncing. Trying on his behalf.
Original Message
Subject:Re: [C++0x] contiguous bitfields race implementation
Date: Tue, 09 Aug 2011 09:49:51 -0400
From: Andrew MacLeod
To: Richard Guenther
CC: Aldy Hernandez ,
On Fri, Aug 5, 2011 at 7:25 PM, Aldy Hernandez wrote:
> Alright, I'm back and bearing patches. Firmly ready for the crucifixion you
> will likely submit me to. :)
>
> I've pretty much rewritten everything, taking into account all your
> suggestions, and adding a handful of tests for corner cases
Alright, I'm back and bearing patches. Firmly ready for the crucifixion
you will likely submit me to. :)
I've pretty much rewritten everything, taking into account all your
suggestions, and adding a handful of tests for corner cases we will now
handle correctly.
It seems the minimum needed
On Fri, Jul 29, 2011 at 11:37 AM, Richard Guenther
wrote:
> On Fri, Jul 29, 2011 at 4:12 AM, Aldy Hernandez wrote:
>> On 07/28/11 06:40, Richard Guenther wrote:
>>
>>> Looking at the C++ memory model what you need is indeed simple enough
>>> to recover here. Still this loop does quadratic work f
Yes. Together with the above it looks then optimal.
Attached patch tested on x86-64 Linux.
OK for mainline?
* expr.c (get_bit_range): Handle *MEM_REF's.
Index: expr.c
===
--- expr.c (revision 176824)
+++ expr.c
On 07/28/11 06:40, Richard Guenther wrote:
Looking at the C++ memory model what you need is indeed simple enough
to recover here. Still this loop does quadratic work for a struct with
N bitfield members and a function which stores into all of them.
And that with a big constant factor as you bui
On Fri, Jul 29, 2011 at 4:12 AM, Aldy Hernandez wrote:
> On 07/28/11 06:40, Richard Guenther wrote:
>
>> Looking at the C++ memory model what you need is indeed simple enough
>> to recover here. Still this loop does quadratic work for a struct with
>> N bitfield members and a function which store
On 07/28/2011 04:40 AM, Richard Guenther wrote:
field). Now, the question is of course what to do for DECL_PACKED
fields (I suppose, simply ignore the C++ memory model as C++ doesn't
have a notion of packed or specially (mis-)aligned structs or bitfields).
I think treat them as bitfields for t
I believe that any after-the-fact attempt to recover bitfield boundaries is
going to fail unless you preserve more information during bitfield layout.
Consider
struct {
char : 8;
char : 0;
char : 8;
};
where the : 0 isn't preserved in any way and you can't distinguish
it from struct
On Thu, Jul 28, 2011 at 9:12 PM, Aldy Hernandez wrote:
>
>> Yes. Together with the above it looks then optimal.
>
> Attached patch tested on x86-64 Linux.
>
> OK for mainline?
Ok with the || moved to the next line as per coding-standards.
Thanks,
Richard.
if (TREE_CODE (to) == COMPONENT_REF
&& DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (&bitregion_start,&bitregion_end,
to, tem, bitpos, bitsize);
and shouldn't this test DECL_BIT_FIELD instead of DECL_BIT_FIELD_TYPE?
As I mention
On Wed, Jul 27, 2011 at 5:03 PM, Richard Guenther
wrote:
> On Wed, Jul 27, 2011 at 4:56 PM, Richard Guenther
> wrote:
>> On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther
>> wrote:
>>> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
>
On Wed, Jul 27, 2011 at 7:19 PM, Andrew MacLeod wrote:
> On 07/27/2011 01:08 PM, Aldy Hernandez wrote:
>>
>>> Anyway, I don't think a --param is appropriate to control a flag whether
>>> to allow store data-races to be created. Why not use a regular option
>>> instead?
>>
>> I don't care either w
On Wed, Jul 27, 2011 at 7:36 PM, Aldy Hernandez wrote:
>
>> Oh, and
>>
>> INNERDECL is the actual object being referenced.
>>
>> || (!ptr_deref_may_alias_global_p (innerdecl)
>>
>> is surely not what you want. That asks if *innerdecl is global memory.
>> I suppose you want is_global_var
On Wed, 27 Jul 2011, Andrew MacLeod wrote:
> On 07/27/2011 01:08 PM, Aldy Hernandez wrote:
> >
> > > Anyway, I don't think a --param is appropriate to control a flag whether
> > > to allow store data-races to be created. Why not use a regular option
> > > instead?
> >
> > I don't care either wa
On 07/27/11 13:55, Jakub Jelinek wrote:
On Wed, Jul 27, 2011 at 01:51:04PM -0500, Aldy Hernandez wrote:
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49875
The assembler sequence on ia32 was a bit different.
H.J. Can you try this on your end? If it fixes the problem, I will
comm
On Wed, Jul 27, 2011 at 01:51:04PM -0500, Aldy Hernandez wrote:
> >This caused:
> >
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49875
>
> The assembler sequence on ia32 was a bit different.
>
> H.J. Can you try this on your end? If it fixes the problem, I will
> commit as obvious.
You could
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49875
The assembler sequence on ia32 was a bit different.
H.J. Can you try this on your end? If it fixes the problem, I will
commit as obvious.
Aldy
PR middle-end/49875
* c-c++-common/cxxbitfields-4.c: Check for sm
On Mon, Jul 25, 2011 at 10:07 AM, Aldy Hernandez wrote:
> On 07/22/11 13:44, Jason Merrill wrote:
>>
>> On 07/18/2011 08:02 AM, Aldy Hernandez wrote:
>>>
>>> + /* If other threads can't see this value, no need to restrict
>>> stores. */
>>> + if (ALLOW_STORE_DATA_RACES
>>> + || !DECL_THREAD_VISIBL
Oh, and
INNERDECL is the actual object being referenced.
|| (!ptr_deref_may_alias_global_p (innerdecl)
is surely not what you want. That asks if *innerdecl is global memory.
I suppose you want is_global_var (innerdecl)? But with
&& (DECL_THREAD_LOCAL_P (innerdecl)
On 07/27/2011 01:08 PM, Aldy Hernandez wrote:
Anyway, I don't think a --param is appropriate to control a flag whether
to allow store data-races to be created. Why not use a regular
option instead?
I don't care either way. What -foption-name do you suggest?
Well, I suggested a -f option se
Anyway, I don't think a --param is appropriate to control a flag whether
to allow store data-races to be created. Why not use a regular option instead?
I don't care either way. What -foption-name do you suggest?
On Wed, Jul 27, 2011 at 4:56 PM, Richard Guenther
wrote:
> On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther
> wrote:
>> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
>>> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
> I think the adjustment above is intended to match the adjust
On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther
wrote:
> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
>> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
>>>
I think the adjustment above is intended to match the adjustment of the
address by bitregion_start/BITS_PER_UNIT, but the
On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
>>
>>> I think the adjustment above is intended to match the adjustment of the
>>> address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
>>> that bitregion_start%BITS_PER_UNIT ==
On 07/25/11 18:55, Jason Merrill wrote:
On 07/25/2011 10:07 AM, Aldy Hernandez wrote:
I had changed this already to take into account aliasing, so if we get
an INDIRECT_REF, ptr_deref_may_alias_global_p() returns true, and we
proceed with the restriction:
Sounds good. "global" includes malloc'
+ bitnum -= bitregion_start;
+ bitregion_end -= bitregion_start;
+ bitregion_start = 0;
Why is this necessary/useful?
You mean, why am I resetting these values (because the call to
get_best_mode() following it needs the adjusted values). Or why am I
adjusting the address to point to the b
On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
I think the adjustment above is intended to match the adjustment of the
address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
that bitregion_start%BITS_PER_UNIT == 0.
That was intentional. bitregion_start always falls on a byte b
On 07/26/2011 09:36 AM, Aldy Hernandez wrote:
+ bitnum -= bitregion_start;
+ bitregion_end -= bitregion_start;
+ bitregion_start = 0;
Why is this necessary/useful?
You mean, why am I resetting these values (because the call to
get_best_mode() following it needs the adjusted values). Or why
I think the adjustment above is intended to match the adjustment of the
address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
that bitregion_start%BITS_PER_UNIT == 0.
That was intentional. bitregion_start always falls on a byte boundary,
does it not?
struct {
stuf
On 07/25/2011 10:07 AM, Aldy Hernandez wrote:
I had changed this already to take into account aliasing, so if we get
an INDIRECT_REF, ptr_deref_may_alias_global_p() returns true, and we
proceed with the restriction:
Sounds good. "global" includes malloc'd memory, right? There don't
seem to b
On 07/22/11 13:44, Jason Merrill wrote:
On 07/18/2011 08:02 AM, Aldy Hernandez wrote:
+ /* If other threads can't see this value, no need to restrict
stores. */
+ if (ALLOW_STORE_DATA_RACES
+ || !DECL_THREAD_VISIBLE_P (innerdecl))
+ {
+ *bitstart = *bitend = 0;
+ return;
+ }
What if get_inner_
On 07/18/2011 08:02 AM, Aldy Hernandez wrote:
+ /* If other threads can't see this value, no need to restrict stores. */
+ if (ALLOW_STORE_DATA_RACES
+ || !DECL_THREAD_VISIBLE_P (innerdecl))
+{
+ *bitstart = *bitend = 0;
+ return;
+}
What if get_inner_reference returns
On 05/27/11 14:18, Jason Merrill wrote:
On 05/26/2011 02:37 PM, Aldy Hernandez wrote:
The narrowest integer mode containing the bit field is still 32, so we
access the bitfield with an SI instruction as expected.
OK, then:
struct A
{
int i: 4;
int j: 4;
int k: 8;
int l: 8;
int m: 8;
};
now t
On 05/26/2011 02:37 PM, Aldy Hernandez wrote:
The narrowest integer mode containing the bit field is still 32, so we
access the bitfield with an SI instruction as expected.
OK, then:
struct A
{
int i: 4;
int j: 4;
int k: 8;
int l: 8;
int m: 8;
};
now the narrowest mode containing 'j
What padding? bitregion_end-bitregion_start+1 will be 32, but in
Poop, I misread your example.
get_best_mode I see
+ maxbits = bitregion_end - bitpos + 1;
which is 28. No?
Yes, but if you look at the next few lines you'll see:
/* Find the narrowest integer mode that contains the bit
On 05/26/2011 01:39 PM, Aldy Hernandez wrote:
On 05/26/11 12:24, Jason Merrill wrote:
struct A
{
int i: 4;
int j: 28;
};
we won't use SImode to access A::j because we're setting maxbits to 28.
No, maxbits is actually 32, because we include padding. So it's correct
in this case.
What pad
On 05/26/11 12:24, Jason Merrill wrote:
I'm afraid I think this is still wrong; the computation of maxbits in
various places assumes that the bitfield is at the start of the unit
we're going to access, so given
struct A
{
int i: 4;
int j: 28;
};
we won't use SImode to access A::j because we're
I'm afraid I think this is still wrong; the computation of maxbits in
various places assumes that the bitfield is at the start of the unit
we're going to access, so given
struct A
{
int i: 4;
int j: 28;
};
we won't use SImode to access A::j because we're setting maxbits to 28.
Jason
On 05/18/11 16:58, Jason Merrill wrote:
It seems like you're calculating maxbits correctly now, but an access
doesn't necessarily start from the beginning of the sequence of
bit-fields, especially given store_split_bit_field. That is,
This is what I was trying to explain to you on irc. And I o
It seems like you're calculating maxbits correctly now, but an access
doesn't necessarily start from the beginning of the sequence of
bit-fields, especially given store_split_bit_field. That is,
struct A
{
int i;
int j: 32;
int k: 8;
char c[2];
};
Here maxbits would be 40, so we decid
Bootstrapped without any issues. Running the entire testsuite with
--param=allow-store-data-races=0 is still in progress.
BTW, no regressions, even running the entire thing at
--param=allow-store-data-races=0 to force testing this new bitfield
implementation on all tests.
On 05/09/11 14:23, Jason Merrill wrote:
From a quick look it seems that this patch considers bitfields
following the one we're deliberately touching, but not previous
bitfields in the same memory location; we need to include those as well.
With your struct foo, the bits touched are the same rega
On Mon, May 9, 2011 at 8:54 PM, Jakub Jelinek wrote:
> On Mon, May 09, 2011 at 01:41:13PM -0500, Aldy Hernandez wrote:
>> Jakub also gave me a testcase which triggered a buglet in
>> max_field_size. I have now added a parameter INNERDECL which is the
>> inner reference, so we can properly determi
From a quick look it seems that this patch considers bitfields
following the one we're deliberately touching, but not previous
bitfields in the same memory location; we need to include those as well.
With your struct foo, the bits touched are the same regardless of
whether we name .a or .b.
On Mon, May 09, 2011 at 01:41:13PM -0500, Aldy Hernandez wrote:
> Jakub also gave me a testcase which triggered a buglet in
> max_field_size. I have now added a parameter INNERDECL which is the
> inner reference, so we can properly determine if the inner decl is
> thread visible or not.
What I me
Tested on x86-64 both with and without "--param
allow-store-data-races=0", and visually inspecting the assembly on
arm-linux and ia64-linux.
Any way to add a test to the testsuite?
I was able to find a testcase for i386/x86_64 by making the bitfield
volatile (similar to the problem in PR4812
On 05/09/11 11:26, Aldy Hernandez wrote:
>
>>> struct
>>> {
>>> unsigned int a : 4;
>>> unsigned char b;
>>> unsigned int c: 6;
>>> } var;
>
>
>> Well, the kernel guys would like to be able to be able to preserve the
>> padding bits too. It's a long long sad story that I won't re
struct
{
unsigned int a : 4;
unsigned char b;
unsigned int c: 6;
} var;
Well, the kernel guys would like to be able to be able to preserve the
padding bits too. It's a long long sad story that I won't repeat...
And I don't think we should further complicate this stuff with th
On 05/09/11 10:24, Aldy Hernandez wrote:
> Seeing that the current C++ draft has been approved, I'd like to submit
> this for mainline, and get the proper review everyone's being quietly
> avoiding :).
>
> To refresh everyone's memory, here is the problem:
>
> struct
> {
> unsigned int a : 4;
Seeing that the current C++ draft has been approved, I'd like to submit
this for mainline, and get the proper review everyone's being quietly
avoiding :).
To refresh everyone's memory, here is the problem:
struct
{
unsigned int a : 4;
unsigned char b;
unsigned int c: 6;
} var;
vo
82 matches
Mail list logo
