From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 6B7FE386191C; Wed, 31 Mar 2021 10:05:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6B7FE386191C
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyBsdG8vOTk4MjhdIGlubGluaW5nIGZhaWxlZCBpbiBjYWxs?=
 =?UTF-8?B?IHRvIOKAmGFsd2F5c19pbmxpbmXigJkg4oCYbWVtY3B54oCZOiAtLXBhcmFt?=
 =?UTF-8?B?IG1heC1pbmxpbmUtaW5zbnMtYXV0byBsaW1pdCByZWFjaGVk?=
Date: Wed, 31 Mar 2021 10:05:12 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
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: <bug-99828-4-82QHwnIlrs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99828-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99828-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2021 10:05:12 -0000

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 31 Mar 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99828
>=20
> --- Comment #8 from Martin Li=C5=A1ka <marxin at gcc dot gnu.org> ---
> All right, I vanished the test-case:
>=20
> $ cat 1.i
> inline __attribute__((__always_inline__)) __attribute__((gnu_inline)) voi=
d *
> memcpy();
> void *apply_relocate_add_write =3D memcpy;
>=20
> $ touch 2.s
> $ cat 3.i
> enum { false, true } * __memcpy();

??  obviously bad reduction.

> _Bool kasan_check_range();
> void *memcpy(void *dest, void *src, long len) {
>   if (kasan_check_range(len, false, 0) || kasan_check_range(len, true, 0))
>     return __memcpy(dest, src, len);
> }
>=20
> long LZ4_decompress_generic_dst_restSize;
> char LZ4_decompress_generic_dst_lowPrefix;
> void LZ4_decompress_generic_dst() {
>   __builtin_memcpy(LZ4_decompress_generic_dst,
>                    &LZ4_decompress_generic_dst_lowPrefix,
>                    LZ4_decompress_generic_dst_restSize);

I wonder if this use of __builtin_memcpy intends to not use the
kernels always-inline memcpy but GCCs own inline expansion?
This obviously doesn't work, not with LTO at least.

It looks like with kasan enabled (and memcpy "wrapped") the
memcpy declaration should _not_ have the always-inline (since
the implementation is no longer always-inline).  That would be
a fix on the kernel side, but I'd also diagnose any such
always-inline "mismatch" we get to at WPA.=