Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3114108imb; Tue, 5 Mar 2019 01:00:41 -0800 (PST) X-Google-Smtp-Source: APXvYqw7eh6ZoZOulHNdmLNtc3MW6/FJ8ew79Cge+PF0+Y2yQDr4Fbi2Lp/mSlzDKAg+RJx4jOx1 X-Received: by 2002:a62:568e:: with SMTP id h14mr851957pfj.134.1551776441018; Tue, 05 Mar 2019 01:00:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551776441; cv=none; d=google.com; s=arc-20160816; b=I8CIg+ePK+vsgIGNcxMMRFaXyT2iwvtGA0aQbJIRrTFeEtwjKuG1lWc+48hlnUIp9S JsOXdqkCKWJIopNOIBo1ll/zJ8if6IFH2II1ezZj5tuHJCEjp90/XrFfIaYJdpQCLWFV ks4GTMZVfShaMrk01ONQ4keLtt4NXT0qOwKwb20CXfA4PXzuQLOSADV+AF2TAzz8XHYe Nx7ihCLqQO9rVHNji2uXePRvIhaPrWolSk7iDQVzeHXpaEERHmhkS5Wkz51P0zzO6d1M RKCD9hkfibuDPoJj3FzpWMDLztXGhOi+4CXZROqauLnfM7xY3LEbwV0lco+v9P+hVUkg ce/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=zCq+KAARny1VMm+ZSe7DkTgUuiWVnBvdcW1fmU8OR+8=; b=EwXodJMf3Fasg98NhV05SNpR6pJaSKaMp/F79mUG5iqg2Vl531zW3hhv1ZznYYxvo1 GeNXG1fu8HRd1Iqop/5R1WFOSCSHMZG+mv6I3psxQVTiddCOhsWa0KFY0MqD338pOoE3 Q0OSTu8dQKo5y1T90E0+AJ03QV//OdLTFa3aHlEA7hwEMZrZU7pktRttUO/Bbeb9nIoE /YuWFrGwiNJpF15ZelmgwM6teG7JXZx4BOGEEajV4FbYxU2To9+pLwPAuRGJIZRJU+Pk q3GiqHw7iC2BFXf0v3oE2HcShrL+dS51mBGh/o9JvI4a3Y0/4GTbM2/kDskeaczukRiP 6hPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d1si7114468pgv.580.2019.03.05.01.00.25; Tue, 05 Mar 2019 01:00:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726098AbfCEI6p (ORCPT + 99 others); Tue, 5 Mar 2019 03:58:45 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:48488 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725818AbfCEI6p (ORCPT ); Tue, 5 Mar 2019 03:58:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 7939D28587; Tue, 5 Mar 2019 03:58:39 -0500 (EST) Date: Tue, 5 Mar 2019 19:58:54 +1100 (AEDT) From: Finn Thain To: Geert Uytterhoeven cc: kbuild test robot , kbuild-all@01.org, linux-m68k , Arnd Bergmann , Linux Kernel Mailing List Subject: Re: [m68k:master 1174/1174] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset 8 is out of the bounds [0, 7] In-Reply-To: Message-ID: References: <201903042049.npxcZzps%fengguang.wu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Mar 2019, Geert Uytterhoeven wrote: > On Tue, Mar 5, 2019 at 3:58 AM Finn Thain wrote: > > On Tue, 5 Mar 2019, Finn Thain wrote: > > > Looks bogus to me. > > > > > > If you change memcpy to __builtin_memcpy, then we avoid the macro and the > > > warning changes to, > > > > > > ./include/linux/string.h:456:3: warning: '__builtin_memcpy' forming offset [7, 8] is out of the bounds [0, 6] [-Warray-bounds] > > > __builtin_memcpy(dest, src, dest_len); > > > > > > The compiler has nothing to complain about here. dest is known to be > > > id->fr and dest_len is known to be sizeof(id->fr). > > > > > > The error message indicates that gcc has applied the bounds [0, 6] to dest > > > when in fact those are the bounds for src. > > > > > > > My mistake. GCC is right, it seems memcpy will read past the end of > > "5.0.0+". > > But only if the else branch is taken, which is not the case. > You and I know that, because we can see what values get passed to memcpy_and_pad(). But how is gcc to know that? If we replace strlen with __builtin_strlen, this problem goes away. It's interesting that the kernel's strlen implementation in include/linux/string.h can't achieve this. -- > Gr{oetje,eeting}s, > > Geert > >