From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D728E383E82A; Tue, 16 Jun 2020 06:57:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D728E383E82A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1592290658; bh=S2FcVNyCR2e2jVcrjb8l9XNWGqhvJiyUlFaOiTPd5Xs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Qea6FiaqZM6FRrM3f6SVRyTtgQx8IIKJWXd1GFCZ+mvEHIkLkM+TvggUcQmNCparx SLU+PAdzx5aaLN9K+4Klu25DGDlCy0lBo/lT50kBYMKwtqcTOhrmV+HjeJWj1JOnyD erFNCP+fOgXYXZQuJyDFunuyfYWXKwypBzN+/RmQ= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior Date: Tue, 16 Jun 2020 06:57:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: alias, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 06:57:39 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95349 --- Comment #40 from rguenther at suse dot de --- On Mon, 15 Jun 2020, richard-gccbugzilla at metafoo dot co.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95349 >=20 > --- Comment #37 from Richard Smith --- > (In reply to Richard Biener from comment #36) > > The main issue I see is that this differing expectations of C and C++ a= re > > impossible to get correct at the same time. >=20 > That is a rather bold claim. I think you can satisfy both rule sets by us= ing > the C++ rule even in C. It is conservatively correct to discard the effec= tive / > dynamic type when you see a memcpy, and the C++ semantics require you to = do so. >=20 > The C semantics also appear to require the same thing, if you cannot trac= k the > destination back to either an object with a declared type or to a heap > allocation; as described in comment#35, GCC gets this wrong and presumably > miscompiles C code in some cases as a result. I very much would like to see such an example! The current GCC rule is quite simple - every store to memory alters the dynamic type of the stored to object to that of the store. Up to now we've had more success with that model than any other we tried before. > It seems to me that all you're allowed to do within the bounds of conform= ance > is: >=20 > #1 if you can track the destination back to an object with declared type = in C > code, then use its type as the effective type of the result >=20 > #2 if you can track the destination back to a heap allocation in C code, = then > copy the effective type from source to destination >=20 > #3 otherwise (in either C or C++) erase the effective type of the destina= tion >=20 > (#1 and #3 will presumably result in memcpy being replaced by some operat= ion > that updates the effective type, rather than being eliminated entirely.) Indeed. Such "operation that updates the effective type" would have come handy in a few cases already, but we do not have it right now and given past experience with variants of it (bad one, obviously) I'm not too keen of re-introducing it. That GCC elideds the memcpy roundtrip is (in the above model where every store alters the dynamic type) a bug - the memcpy internally actually discards the dynamic type info. The option of having to preserve that roundtrip isn't very appealing though. We've went to that way for cases where we now cannot remove a "redundant" store (a store with the same bit pattern but different effective type). Bottom line is I wouldn't hold my breath getting this fixed on the GCC side. Like with the partial object re-use and aggregate assignment case the C++ FE will have the option disabling type-based alias-analysis completely for some objects (but I can't see how that helps with the case referenced here).=