Re: gcc 4.5.1 -fstrict-aliasing and store removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Vyacheslav Egorov <vegorov@xxxxxxxxxxxx> writes:

> I am experiencing the following problem when compiling V8[1] with gcc
> 4.5.1 with -O1 -fstrict-aliasing enabled: for some reason GCC removes
> one of the stores to memory.
>
> Store removal happens in the method Genesis::HookUpGlobalProxy [2]
>
> void Genesis::HookUpGlobalProxy(Handle<GlobalObject> inner_global,
> Handle<JSGlobalProxy> global_proxy) {
>   // ...
>   inner_global->set_global_context(*global_context());
>   // ...
> }
>
>  GCC inlines method GlobalObject::set_global_context, which is defined
> through macroses ACCESSORS[3] and WRITE_FIELD[4]
>
>   void GlobalObject::set_global_context(Context* value, WriteBarrierMode mode) {
>     WRITE_FIELD(this, offset, value);
>     CONDITIONAL_WRITE_BARRIER(this, offset, mode);
>   }
>
> #define FIELD_ADDR(p, offset) \
>   (reinterpret_cast<byte*>(p) + offset - kHeapObjectTag)
>
> #define WRITE_FIELD(p, offset, value) \
>   (*reinterpret_cast<Object**>(FIELD_ADDR(p, offset)) = value)
>
> and removes memory store which should be generated from WRITE_FIELD.
>
> I am trying to figure out why GCC decides that this memory store can
> be safely removed.

It's pretty hard to say anything conclusive about an incomplete example,
but the use of reinterpret_cast and -fstrict-aliasing obviously suggests
an aliasing violation.

Perhaps you could explain why this is not an aliasing violation?

(When your program has an aliasing violation, gcc does unpredictable
things.  There is little benefit to speculating about precisely why it
did what it did.)

Ian


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux