This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 29 Apr 2016 17:44:59 +0000
- Subject: [Bug rtl-optimization/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
- Auto-submitted: auto-generated
- References: <bug-70526-4 at http dot gcc dot gnu dot org/bugzilla/>
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)