From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C93B822492746 for ; Fri, 2 Mar 2018 10:03:21 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EEF347B4AD; Fri, 2 Mar 2018 18:09:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-125-62.rdu2.redhat.com [10.10.125.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id C9D312024CA8; Fri, 2 Mar 2018 18:09:29 +0000 (UTC) From: Laszlo Ersek To: edk2-devel-01 Cc: Ard Biesheuvel , Cole Robinson , Liming Gao , Paolo Bonzini , Yonghong Zhu Date: Fri, 2 Mar 2018 19:09:23 +0100 Message-Id: <20180302180924.4312-3-lersek@redhat.com> In-Reply-To: <20180302180924.4312-1-lersek@redhat.com> References: <20180302180924.4312-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 02 Mar 2018 18:09:31 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 02 Mar 2018 18:09:31 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: [PATCH 2/3] BaseTools/header.makefile: add "-Wno-restrict" X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 18:03:22 -0000 gcc-8 (which is part of Fedora 28) enables the new warning "-Wrestrict" in "-Wall". This warning is documented in detail at ; the introduction says > Warn when an object referenced by a restrict-qualified parameter (or, in > C++, a __restrict-qualified parameter) is aliased by another argument, > or when copies between such objects overlap. It breaks the BaseTools build (in the Brotli compression library) with: > In function 'ProcessCommandsInternal', > inlined from 'ProcessCommands' at dec/decode.c:1828:10: > dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631 > bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at > offset 16 [-Werror=restrict] > memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16)); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In function 'ProcessCommandsInternal', > inlined from 'SafeProcessCommands' at dec/decode.c:1833:10: > dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631 > bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at > offset 16 [-Werror=restrict] > memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16)); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paolo Bonzini analyzed the Brotli source in detail, and concluded that the warning is a false positive: > This seems safe to me, because it's preceded by: > > uint8_t* copy_dst = &s->ringbuffer[pos]; > uint8_t* copy_src = &s->ringbuffer[src_start]; > int dst_end = pos + i; > int src_end = src_start + i; > if (src_end > pos && dst_end > src_start) { > /* Regions intersect. */ > goto CommandPostWrapCopy; > } > > If [src_start, src_start + i) and [pos, pos + i) don't intersect, then > neither do [src_start + 16, src_start + i) and [pos + 16, pos + i). > > The if seems okay: > > (src_start + i > pos && pos + i > src_start) > > which can be rewritten to: > > (pos < src_start + i && src_start < pos + i) > > Then the numbers are in one of these two orders: > > pos <= src_start < pos + i <= src_start + i > src_start <= pos < src_start + i <= pos + i > > These two would be allowed by the "if", but they can only happen if pos > == src_start so they degenerate to the same two orders above: > > pos <= src_start < src_start + i <= pos + i > src_start <= pos < pos + i <= src_start + i > > So it is a false positive in GCC. Disable the warning for now. Cc: Ard Biesheuvel Cc: Cole Robinson Cc: Liming Gao Cc: Paolo Bonzini Cc: Yonghong Zhu Reported-by: Cole Robinson Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- BaseTools/Source/C/Makefiles/header.makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BaseTools/Source/C/Makefiles/header.makefile b/BaseTools/Source/C/Makefiles/header.makefile index 550f8b35bce2..065a998bf5de 100644 --- a/BaseTools/Source/C/Makefiles/header.makefile +++ b/BaseTools/Source/C/Makefiles/header.makefile @@ -71,9 +71,9 @@ INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I $(MAKE BUILD_CPPFLAGS = $(INCLUDE) -O2 ifeq ($(DARWIN),Darwin) # assume clang or clang compatible flags on OS X -BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-self-assign -Wno-unused-result -nostdlib -c -g +BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-self-assign -Wno-unused-result -nostdlib -c -g else -BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-unused-result -nostdlib -c -g +BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-unused-result -nostdlib -c -g endif BUILD_LFLAGS = BUILD_CXXFLAGS = -Wno-unused-result -- 2.14.1.3.gb7cf6e02401b