This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On April 29, 2016 5:24:00 PM GMT+02:00, "amonakov at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
>
>Alexander Monakov <amonakov at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>            CC|                            |amonakov at gcc dot gnu.org
>
>--- Comment #18 from Alexander Monakov <amonakov at gcc dot gnu.org>
>---
>Richard -- please correct if I'm wrong -- means here:
>
>> You can't refer to that part of the storage by copying *this.
>
>... that the implicitly instantiated copy constructor (as well as
>assignment
>operator, for that matter) will copy this->typed as a char[]/uint64_t
>union,
>while it actually contains a value of type Register. You need an
>explicit copy
>constructor that would assign this->typed with the correct type via
>'typed.addr() = ...' like the existing constructor does.

Yes.  In fact the C++ FE for the copy constructor emits a simple aggregate
assignment which may be a problem on its own (regarding TBAA if this case is
supposed to be not invalid)

>(If T was POD, you could have had it in the union in the first place,
>and this
>issue wouldn't arise)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]