http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #15 from Tomohiro Kashiwada 2011-10-29
14:37:15 UTC ---
I see. Thanks detail exposition.
I think the behavior of my patch seems correct and it should be merged.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #14 from Henrik Nordström
2011-10-29 10:45:53 UTC ---
(In reply to comment #13)
> > See 7.1.7.5 second and third paragraph and the note just after.
>
> Is that means a statement
> a = b;
> always should be treat as if
> tmp = b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #13 from Tomohiro Kashiwada 2011-10-29
06:50:11 UTC ---
(In reply to comment #12)
> Regarding the double load. In a statement like a = b, both a & be should be
> individually accessed even if they refer to the same storage. So
> bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #12 from Henrik Nordström
2011-10-28 17:46:15 UTC ---
Regarding the double load. In a statement like a = b, both a & be should be
individually accessed even if they refer to the same storage. So
bitfield.bits.a = bitfield.bits.c sho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #11 from Tomohiro Kashiwada 2011-10-28
08:15:39 UTC ---
Created attachment 25642
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25642
patch to honor STRICT_ALIGNMENT
honor STRICT_ALIGNMENT when accessing non-volatile-bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #10 from Tomohiro Kashiwada 2011-10-28
08:13:31 UTC ---
(In reply to comment #9)
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
> section 7.1.7.5.
Thanks, I see.
On ARM ABI, reading or writing to volat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #9 from Henrik Nordström
2011-10-28 07:32:48 UTC ---
C standard does not define any of this It's all implementation and platform ABI
dependent.
The C standard does define not storage size of a bit-field other than that it's
suffici
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #8 from Tomohiro Kashiwada 2011-10-28
03:58:45 UTC ---
(In reply to comment #7)
> Right. r171347 seem to be about fetches from bitfields while this change is
> about stores?
>
> An interesting test would be
>
> bitfield.bits.a =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #7 from Henrik Nordström
2011-10-28 01:59:34 UTC ---
Right. r171347 seem to be about fetches from bitfields while this change is
about stores?
An interesting test would be
bitfield.bits.a = bitfield.bits.c
which should load the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #6 from Tomohiro Kashiwada 2011-10-28
01:32:42 UTC ---
(In reply to comment #5)
> Is this related to the strict volatile bitfields change in trunk revision
> 171347?
> http://gcc.gnu.org/viewcvs/trunk/gcc/expr.c?view=log&pathrev=17134
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
Henrik Nordström changed:
What|Removed |Added
CC||henrik at henriknordstrom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #4 from Tomohiro Kashiwada 2011-10-20
01:53:33 UTC ---
Created attachment 25559
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25559
proposal patch
fix generating wrong code. no longer volatile-bitfield breaks other field.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #3 from Tomohiro Kashiwada 2011-09-27
04:15:19 UTC ---
Other test case (gcc generates wrong code):
volatile union {
// add volatiles tenaciously, but...
volatile unsigned int all;
volatile struct {
volatile unsign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #2 from Tomohiro Kashiwada 2011-09-26
11:42:37 UTC ---
Variable 'bitfield' declared as volatile, so all bitfield's members are
volatile.
Even if declare 'bits' as volatile, gcc dumps same code.
However, adding option -fno-strict-volat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #1 from Richard Guenther 2011-09-26
10:48:15 UTC ---
I don't think volatile union bitfield constitutes a "volatile bitfield" as
per what GCC implements.
15 matches
Mail list logo
