Hmm, yeah. Or something like
Index: expr.c
===
--- expr.c (revision 186082)
+++ expr.c (working copy)
@@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
bitoffset += (tree_low_cst
On Tue, 3 Apr 2012, Eric Botcazou wrote:
Hmm, yeah. Or something like
Index: expr.c
===
--- expr.c (revision 186082)
+++ expr.c (working copy)
@@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder
why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
DECL_FIELD_OFFSET is added to offset and DECL_FIELD_BIT_OFFSET to bitpos.
So,
On Tue, 3 Apr 2012, Eric Botcazou wrote:
For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder
why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
DECL_FIELD_OFFSET is added to
On Fri, 30 Mar 2012, Eric Botcazou wrote:
May I apply the patch I posted? It boostrapped/regtested fine on
x86-64/Linux.
Yes.
Thanks. Unfortunately, while this was the last identified problem on x86,
another issue is visible on x86-64 as a miscompilation of XML/Ada at -O0.
May I apply the patch I posted? It boostrapped/regtested fine on
x86-64/Linux.
Yes.
Thanks. Unfortunately, while this was the last identified problem on x86,
another issue is visible on x86-64 as a miscompilation of XML/Ada at -O0.
Reduced testcase attached:
gnat.dg/pack18.adb
On Mon, 26 Mar 2012, Eric Botcazou wrote:
Uh. When is a field a bit field though? At least stor-layout.c
resets DECL_BIT_FIELD
when local relative alignment is proper and the filed has an integer
mode. That's
overly optimistic if the record is placed at a bit position. Of
course
On Mon, 26 Mar 2012, Eric Botcazou wrote:
The patch looks reasonable - can we compute this backward from the
result of the outer get_inner_reference call and the outermost
field-decl though? Or make get_inner_reference compute that while
analyzing the full reference and return a flag?
Btw, I put things in stor-layout.c exactly to allow a langhook
eventually controlling things for the bitfield representative.
Mind adding one that simply disables them completely for Ada?
Or maybe, for selected record types, so that we do
if (lang_hooks.types.lower_bitfield_layout (rli-t))
On Tue, 27 Mar 2012, Eric Botcazou wrote:
Btw, I put things in stor-layout.c exactly to allow a langhook
eventually controlling things for the bitfield representative.
Mind adding one that simply disables them completely for Ada?
Or maybe, for selected record types, so that we do
if
I see. Though the code does not affect layout but only access layout
for bitfields. I'm fine with fixing the issues we run into elsewhere,
just the langhook is a possibility I had in mind from the start, in
case frontends differ in their memory model for bitfields.
Understood. According to
Huh? If they have DECL_FIELD_BIT_OFFSET of zero they are at a byte
boundary, no? Wait - the RECORD_TYPE itself is at non-zero
DECL_FIELD_BIT_OFFSET and thus a zero DECL_FIELD_BIT_OFFSET for its
fields does not mean anything?!
DECL_FIELD_BIT_OFFSET is relative to the enclosing record type.
Btw, now checking with gdb, DECL_OFFSET_ALIGN is always 128 for
all of the fields - that looks bogus. DECL_ALIGN is 1, but that
doesn't mean DECL_OFFSET_ALIGN should not be 1 as well, no?
DECL_OFFSET_ALIGN is set to BIGGEST_ALIGNMENT for the first field, see
start_record_layout. If
I think we indeed can't really in stor-layout, so the only place is very
likely get_bit_range.
Something like that for example. I think the expmed.c hunk should be applied
to the 4.7 branch as well, because the new code in store_bit_field is quite
dangerous without it.
* expmed.c
OTOH if DECL_ALIGN is absolute then if the first field of a record type has
DECL_ALIGN that is a multiple of BITS_PER_UNIT we know we can use
the present stor-layout code? So we can check that and give up computing
representatives at all for a record type if that does not hold.
I don't think
On Mon, Mar 26, 2012 at 10:17 AM, Eric Botcazou ebotca...@adacore.com wrote:
OTOH if DECL_ALIGN is absolute then if the first field of a record type has
DECL_ALIGN that is a multiple of BITS_PER_UNIT we know we can use
the present stor-layout code? So we can check that and give up computing
On Mon, 26 Mar 2012, Eric Botcazou wrote:
I think we indeed can't really in stor-layout, so the only place is very
likely get_bit_range.
Something like that for example. I think the expmed.c hunk should be applied
to the 4.7 branch as well, because the new code in store_bit_field is
Uh. When is a field a bit field though? At least stor-layout.c
resets DECL_BIT_FIELD
when local relative alignment is proper and the filed has an integer
mode. That's
overly optimistic if the record is placed at a bit position. Of
course we still have
DECL_BIT_FIELD_TYPE, but I wonder
The patch looks reasonable - can we compute this backward from the
result of the outer get_inner_reference call and the outermost
field-decl though? Or make get_inner_reference compute that while
analyzing the full reference and return a flag? OTOH it shouldn't
be too expensive.
There are
On Thu, 22 Mar 2012, Richard Guenther wrote:
On Thu, 22 Mar 2012, Eric Botcazou wrote:
bitregion_start == 11 looks bogus. The representative is starting at
DECL_FIELD_BIT_OFFSET (repr)
= size_binop (BIT_AND_EXPR,
DECL_FIELD_BIT_OFFSET (field),
This is what I have applied after bootstrapping and testing on
x86_64-unknown-linux-gnu.
Thanks. Last identified problem: the miscompilation with variant record.
gnat.dg/pack17.adb
raised PROGRAM_ERROR : pack17.adb:36 explicit raise
FAIL: gnat.dg/pack17.adb execution test
Things start to
On Thu, 22 Mar 2012, Eric Botcazou wrote:
This is what I have applied after bootstrapping and testing on
x86_64-unknown-linux-gnu.
Thanks. Last identified problem: the miscompilation with variant record.
gnat.dg/pack17.adb
raised PROGRAM_ERROR : pack17.adb:36 explicit raise
FAIL:
Yes, I have noticed that from what you can see in the code. So the
issue is that get_bit_range tells us that it's ok to touch bits
outside of the field - but that's obviously required. We may not
change bits that are not covered by the FIELD_DECL which now
somehow happens? That sounds like
On Thu, 22 Mar 2012, Eric Botcazou wrote:
Yes, I have noticed that from what you can see in the code. So the
issue is that get_bit_range tells us that it's ok to touch bits
outside of the field - but that's obviously required. We may not
change bits that are not covered by the
But the bitfield group _does_ start on a byte boundary. At least
that's what the new code in stor-layout ensures.
No, it doesn't, since it does the computation on a record by record basis.
Here we have a bitfield group that starts in a record and ends up in a nested
record.
It's ok to
On Thu, Mar 22, 2012 at 12:47 PM, Eric Botcazou ebotca...@adacore.com wrote:
But the bitfield group _does_ start on a byte boundary. At least
that's what the new code in stor-layout ensures.
No, it doesn't, since it does the computation on a record by record basis.
Here we have a bitfield
bitregion_start == 11 looks bogus. The representative is starting at
DECL_FIELD_BIT_OFFSET (repr)
= size_binop (BIT_AND_EXPR,
DECL_FIELD_BIT_OFFSET (field),
bitsize_int (~(BITS_PER_UNIT - 1)));
which looks ok
It cannot be OK if you want it to be
On Thu, 22 Mar 2012, Eric Botcazou wrote:
bitregion_start == 11 looks bogus. The representative is starting at
DECL_FIELD_BIT_OFFSET (repr)
= size_binop (BIT_AND_EXPR,
DECL_FIELD_BIT_OFFSET (field),
bitsize_int (~(BITS_PER_UNIT - 1)));
On Mon, 19 Mar 2012, Richard Guenther wrote:
On Mon, 19 Mar 2012, Eric Botcazou wrote:
But it's only ever computed for RECORD_TYPEs where DECL_QUALIFIER is
unused.
OK, that could work indeed.
For now giving up seems to be easiest (just give up when
DECL_FIELD_OFFSET is not
But it's only ever computed for RECORD_TYPEs where DECL_QUALIFIER is
unused.
OK, that could work indeed.
For now giving up seems to be easiest (just give up when
DECL_FIELD_OFFSET is not equal for all of the bitfield members).
That will at most get you the miscompiles for the PRs back, for
On Mon, 19 Mar 2012, Eric Botcazou wrote:
But it's only ever computed for RECORD_TYPEs where DECL_QUALIFIER is
unused.
OK, that could work indeed.
For now giving up seems to be easiest (just give up when
DECL_FIELD_OFFSET is not equal for all of the bitfield members).
That will at
On Thu, 15 Mar 2012, Eric Botcazou wrote:
Computing the offset in stor-layout.c and storing it in DECL_INITIAL?
Ugh. I just realized that the DECL_BIT_FIELD_REPRESENTATIVE is built during
layout... but is overloaded with DECL_QUALIFIER. That's probably the source
of the miscompilation
1. is easy, see patch below. 2. is much harder - we need to
compute the bit-offset relative to the bitfield group start,
thus in get_bit_range we do
/* Compute the adjustment to bitpos from the offset of the field
relative to the representative. */
offset = size_diffop
Computing the offset in stor-layout.c and storing it in DECL_INITIAL?
Ugh. I just realized that the DECL_BIT_FIELD_REPRESENTATIVE is built during
layout... but is overloaded with DECL_QUALIFIER. That's probably the source
of the miscompilation I talked about earlier.
Can we delay it until
On Fri, 9 Mar 2012, Eric Botcazou wrote:
This patch also completely replaces get_bit_range (which is where
PR52097 ICEs) by a trivial implementation.
How does it short-circuit the decision made by get_best_mode exactly? By
making get_bit_range return non-zero in more cases?
It will
Btw, I _think_ I want GET_MODE_BITSIZE here - we cannot allow
GET_MODE_BITSIZE GET_MODE_PRECISION as that would possibly
access memory that is not allowed. Thus, what GET_MODE_* would
identify the access size used for a MEM of that mode?
I agree that GET_MODE_BITSIZE makes more sense than
This patch also completely replaces get_bit_range (which is where
PR52097 ICEs) by a trivial implementation.
How does it short-circuit the decision made by get_best_mode exactly? By
making get_bit_range return non-zero in more cases?
There is PR52134 which will make this patch cause 1 gnat
37 matches
Mail list logo
