On Wed, Feb 8, 2012 at 3:14 AM, Richard Guenther wrote:
> On Tue, 7 Feb 2012, Jakub Jelinek wrote:
>
>> On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote:
>> > > What would it have said for -fabi-version=1 where for
>> > > we place s.i and s.d into the same byte?
>> >
>> > I think it
On Tue, 7 Feb 2012, Hans-Peter Nilsson wrote:
> On Tue, 7 Feb 2012, Richard Guenther wrote:
> > The following patch rewrites the bitfield handling of the C++ memory
> > model and enables it unconditionally to fix PR52080. As I suggested
> > earlier at some point this moves computation of what the
On Tue, 7 Feb 2012, Jakub Jelinek wrote:
> On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote:
> > > What would it have said for -fabi-version=1 where for
> > > we place s.i and s.d into the same byte?
> >
> > I think it says they shouldn't be in the same byte :-)
>
> They don't, ex
On 02/07/2012 02:23 AM, Richard Guenther wrote:
There are still corner-cases I also pointed out in the existing
get_bit_range code, namely if you consider tail-padding re-use
with C++ inheritance (I didn't try hard to construct a testcase yet).
The C++ memory model folks have not yet expressed th
On 02/07/2012 04:47 AM, Joseph S. Myers wrote:
For C++ the width may depend on a template parameter so the integer value
can't be determined immediately at parse time.
Right. But we don't do any layout in templates, so it should be ok to
do different things for template and non-template cases
On Tue, 7 Feb 2012, Richard Guenther wrote:
> The following patch rewrites the bitfield handling of the C++ memory
> model and enables it unconditionally to fix PR52080. As I suggested
> earlier at some point this moves computation of what the memory model
> considers the underlying object we may
On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote:
> > What would it have said for -fabi-version=1 where for
> > we place s.i and s.d into the same byte?
>
> I think it says they shouldn't be in the same byte :-)
They don't, except for compatibility with the old ABI.
I think easiest
On 7 February 2012 14:00, Richard Guenther wrote:
> On Tue, 7 Feb 2012, Jonathan Wakely wrote:
>
>> Hi Richard,
>>
>> re http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00280.html (I'm not
>> subscribed to gcc-patches so only read it in the archive)
>>
>> > Note that in the above case
>> > tail-paddin
On Tue, 7 Feb 2012, Richard Guenther wrote:
> That would be nice. I suppose that doing
>
> if (DECL_INITIAL (x))
> {
> unsigned HOST_WIDE_INT width = tree_low_cst (DECL_INITIAL (x),
> 1);
> DECL_SIZE (x) = bitsize_int (width);
> DECL_BIT_FIELD (x) = 1
On Tue, 7 Feb 2012, Jonathan Wakely wrote:
> Hi Richard,
>
> re http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00280.html (I'm not
> subscribed to gcc-patches so only read it in the archive)
>
> > Note that in the above case
> > tail-padding is _not_ reused (for some reason).
>
> Tail-padding in
On Tue, 7 Feb 2012, Joseph S. Myers wrote:
> On Tue, 7 Feb 2012, Richard Guenther wrote:
>
> > If the C frontend would stop using DECL_INITIAL temporarily for
> > bitfield FIELD_DECLs we could avoid adding a new member to struct
> > tree_field_decl - Joseph, is it possible to avoid using DECL_INI
On Tue, 7 Feb 2012, Richard Guenther wrote:
> If the C frontend would stop using DECL_INITIAL temporarily for
> bitfield FIELD_DECLs we could avoid adding a new member to struct
> tree_field_decl - Joseph, is it possible to avoid using DECL_INITIAL?
C++ does the same thing with DECL_INITIAL so I'
The following patch rewrites the bitfield handling of the C++ memory
model and enables it unconditionally to fix PR52080. As I suggested
earlier at some point this moves computation of what the memory model
considers the underlying object we may access to the point where we
lay out a structure ty
13 matches
Mail list logo
