[PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Laszlo Ersek]

Repo:   https://github.com/lersek/edk2.git
Branch: basetools_gcc8

Once these patches are applied to the build flags and the source code of
the build utilities themselves, OVMF builds fine with gcc-8, using the
GCC5 toolchain settings without any changes.

Regression-tested with gcc-4.8 / x86_64.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>

Thanks
Laszlo

Laszlo Ersek (3):
  BaseTools/header.makefile: add "-Wno-stringop-truncation"
  BaseTools/header.makefile: add "-Wno-restrict"
  BaseTools/GenVtf: silence false "stringop-overflow" warning with
    memcpy()

 BaseTools/Source/C/Makefiles/header.makefile | 4 ++--
 BaseTools/Source/C/GenVtf/GenVtf.c           | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.14.1.3.gb7cf6e02401b

[PATCH 1/3] BaseTools/header.makefile: add "-Wno-stringop-truncation"

[Laszlo Ersek]

gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-truncation" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says

> Warn for calls to bounded string manipulation functions such as strncat,
> strncpy, and stpncpy that may either truncate the copied string or leave
> the destination unchanged.

It breaks the BaseTools build with:

> EfiUtilityMsgs.c: In function 'PrintMessage':
> EfiUtilityMsgs.c:484:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
>          strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:469:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
>          strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:511:5: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
>      strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The right way to fix the warning would be to implement string concat with
snprintf(). However, Microsoft does not appear to support snprintf()
before VS2015
<https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010>,
so we just have to shut up the warning. The strncat() calls flagged above
are valid BTW.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 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 0976973bdd7b..550f8b35bce2 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-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-self-assign -Wno-unused-result -nostdlib -c -g
 else
-BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-unused-result -nostdlib -c -g
+BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-unused-result -nostdlib -c -g
 endif
 BUILD_LFLAGS =
 BUILD_CXXFLAGS = -Wno-unused-result
-- 
2.14.1.3.gb7cf6e02401b

[PATCH 2/3] BaseTools/header.makefile: add "-Wno-restrict"

[Laszlo Ersek]

gcc-8 (which is part of Fedora 28) enables the new warning
"-Wrestrict" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; 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 <pbonzini@redhat.com> 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 <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Cole Robinson <crobinso@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 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

[PATCH 3/3] BaseTools/GenVtf: silence false "stringop-overflow" warning with memcpy()

[Laszlo Ersek]

gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-overflow" in "-Wall". This warning is documented in detail at
<https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says

> Warn for calls to string manipulation functions such as memcpy and
> strcpy that are determined to overflow the destination buffer.

It breaks the BaseTools build with:

> GenVtf.c: In function 'ConvertVersionInfo':
> GenVtf.c:132:7: error: 'strncpy' specified bound depends on the length
> of the source argument [-Werror=stringop-overflow=]
>        strncpy (TemStr + 4 - Length, Str, Length);
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> GenVtf.c:130:14: note: length computed here
>      Length = strlen(Str);
>               ^~~~~~~~~~~

It is a false positive because, while the bound equals the length of the
source argument, the destination pointer is moved back towards the
beginning of the destination buffer by the same amount (and this amount is
range-checked first, so we can't precede the start of the dest buffer).

Replace both strncpy() calls with memcpy().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Cole Robinson <crobinso@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 BaseTools/Source/C/GenVtf/GenVtf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/GenVtf/GenVtf.c b/BaseTools/Source/C/GenVtf/GenVtf.c
index 65ae08eeceb8..fc7ae02203ff 100644
--- a/BaseTools/Source/C/GenVtf/GenVtf.c
+++ b/BaseTools/Source/C/GenVtf/GenVtf.c
@@ -129,9 +129,9 @@ Returns:
   } else {
     Length = strlen(Str);
     if (Length < 4) {
-      strncpy (TemStr + 4 - Length, Str, Length);
+      memcpy (TemStr + 4 - Length, Str, Length);
     } else {
-      strncpy (TemStr, Str + Length - 4, 4);
+      memcpy (TemStr, Str + Length - 4, 4);
     }
   
     sscanf (
-- 
2.14.1.3.gb7cf6e02401b

Re: [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Gao, Liming]

Reviewed-by: Liming Gao <liming.gao@intel.com>

>-----Original Message-----
>From: Laszlo Ersek [mailto:lersek@redhat.com]
>Sent: Saturday, March 03, 2018 2:09 AM
>To: edk2-devel-01 <edk2-devel@lists.01.org>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Cole Robinson
><crobinso@redhat.com>; Gao, Liming <liming.gao@intel.com>; Paolo Bonzini
><pbonzini@redhat.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
>Subject: [PATCH 0/3] BaseTools: let the C-language build utils compile with
>gcc-8
>
>Repo:   https://github.com/lersek/edk2.git
>Branch: basetools_gcc8
>
>Once these patches are applied to the build flags and the source code of
>the build utilities themselves, OVMF builds fine with gcc-8, using the
>GCC5 toolchain settings without any changes.
>
>Regression-tested with gcc-4.8 / x86_64.
>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Cc: Cole Robinson <crobinso@redhat.com>
>Cc: Liming Gao <liming.gao@intel.com>
>Cc: Paolo Bonzini <pbonzini@redhat.com>
>Cc: Yonghong Zhu <yonghong.zhu@intel.com>
>
>Thanks
>Laszlo
>
>Laszlo Ersek (3):
>  BaseTools/header.makefile: add "-Wno-stringop-truncation"
>  BaseTools/header.makefile: add "-Wno-restrict"
>  BaseTools/GenVtf: silence false "stringop-overflow" warning with
>    memcpy()
>
> BaseTools/Source/C/Makefiles/header.makefile | 4 ++--
> BaseTools/Source/C/GenVtf/GenVtf.c           | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
>--
>2.14.1.3.gb7cf6e02401b

Re: [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Laszlo Ersek]

On 03/05/18 15:13, Gao, Liming wrote:
> Reviewed-by: Liming Gao <liming.gao@intel.com>

Thank you, Liming; I pushed the series as commit range
20203d3f98d6..9de306701312.

Laszlo

>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Saturday, March 03, 2018 2:09 AM
>> To: edk2-devel-01 <edk2-devel@lists.01.org>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Cole Robinson
>> <crobinso@redhat.com>; Gao, Liming <liming.gao@intel.com>; Paolo Bonzini
>> <pbonzini@redhat.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
>> Subject: [PATCH 0/3] BaseTools: let the C-language build utils compile with
>> gcc-8
>>
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: basetools_gcc8
>>
>> Once these patches are applied to the build flags and the source code of
>> the build utilities themselves, OVMF builds fine with gcc-8, using the
>> GCC5 toolchain settings without any changes.
>>
>> Regression-tested with gcc-4.8 / x86_64.
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Cole Robinson <crobinso@redhat.com>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (3):
>>  BaseTools/header.makefile: add "-Wno-stringop-truncation"
>>  BaseTools/header.makefile: add "-Wno-restrict"
>>  BaseTools/GenVtf: silence false "stringop-overflow" warning with
>>    memcpy()
>>
>> BaseTools/Source/C/Makefiles/header.makefile | 4 ++--
>> BaseTools/Source/C/GenVtf/GenVtf.c           | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> --
>> 2.14.1.3.gb7cf6e02401b
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

Re: [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Gao, Liming]

Laszlo:
  We just find this change causes XCODE5 build failure, because XCODE compiler doesn't know these two options. So, could you provide the patch to remove the change in BUILD_CFLAGS for MAC?

ifeq ($(DARWIN),Darwin)
# assume clang or clang compatible flags on OS X
BUILD_CFLAGS =
else

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gao, Liming
> Sent: Monday, March 5, 2018 10:14 PM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; Cole Robinson <crobinso@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8
> 
> Reviewed-by: Liming Gao <liming.gao@intel.com>
> 
> >-----Original Message-----
> >From: Laszlo Ersek [mailto:lersek@redhat.com]
> >Sent: Saturday, March 03, 2018 2:09 AM
> >To: edk2-devel-01 <edk2-devel@lists.01.org>
> >Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Cole Robinson
> ><crobinso@redhat.com>; Gao, Liming <liming.gao@intel.com>; Paolo Bonzini
> ><pbonzini@redhat.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
> >Subject: [PATCH 0/3] BaseTools: let the C-language build utils compile with
> >gcc-8
> >
> >Repo:   https://github.com/lersek/edk2.git
> >Branch: basetools_gcc8
> >
> >Once these patches are applied to the build flags and the source code of
> >the build utilities themselves, OVMF builds fine with gcc-8, using the
> >GCC5 toolchain settings without any changes.
> >
> >Regression-tested with gcc-4.8 / x86_64.
> >
> >Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >Cc: Cole Robinson <crobinso@redhat.com>
> >Cc: Liming Gao <liming.gao@intel.com>
> >Cc: Paolo Bonzini <pbonzini@redhat.com>
> >Cc: Yonghong Zhu <yonghong.zhu@intel.com>
> >
> >Thanks
> >Laszlo
> >
> >Laszlo Ersek (3):
> >  BaseTools/header.makefile: add "-Wno-stringop-truncation"
> >  BaseTools/header.makefile: add "-Wno-restrict"
> >  BaseTools/GenVtf: silence false "stringop-overflow" warning with
> >    memcpy()
> >
> > BaseTools/Source/C/Makefiles/header.makefile | 4 ++--
> > BaseTools/Source/C/GenVtf/GenVtf.c           | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> >--
> >2.14.1.3.gb7cf6e02401b
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Laszlo Ersek]

On 03/07/18 07:43, Gao, Liming wrote:
> Laszlo:
>   We just find this change causes XCODE5 build failure, because XCODE compiler doesn't know these two options. So, could you provide the patch to remove the change in BUILD_CFLAGS for MAC?

Yep, I was a bit concerned about that.

Ultimately I assumed that
- clang would either recognize these warnings options (because it does
  recognize most -W options of gcc),
- or, similarly to gcc, clang would simply ignore -Wno-* flags that it
  does not recognize.

Neither appears to be the case, then. I'll send a patch soon.

Thanks, and sorry about the regression.
Laszlo

> ifeq ($(DARWIN),Darwin)
> # assume clang or clang compatible flags on OS X
> BUILD_CFLAGS =
> else
> 
> Thanks
> Liming
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gao, Liming
>> Sent: Monday, March 5, 2018 10:14 PM
>> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>; Cole Robinson <crobinso@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Subject: Re: [edk2] [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8
>>
>> Reviewed-by: Liming Gao <liming.gao@intel.com>
>>
>>> -----Original Message-----
>>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>>> Sent: Saturday, March 03, 2018 2:09 AM
>>> To: edk2-devel-01 <edk2-devel@lists.01.org>
>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Cole Robinson
>>> <crobinso@redhat.com>; Gao, Liming <liming.gao@intel.com>; Paolo Bonzini
>>> <pbonzini@redhat.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
>>> Subject: [PATCH 0/3] BaseTools: let the C-language build utils compile with
>>> gcc-8
>>>
>>> Repo:   https://github.com/lersek/edk2.git
>>> Branch: basetools_gcc8
>>>
>>> Once these patches are applied to the build flags and the source code of
>>> the build utilities themselves, OVMF builds fine with gcc-8, using the
>>> GCC5 toolchain settings without any changes.
>>>
>>> Regression-tested with gcc-4.8 / x86_64.
>>>
>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> Cc: Cole Robinson <crobinso@redhat.com>
>>> Cc: Liming Gao <liming.gao@intel.com>
>>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>>> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
>>>
>>> Thanks
>>> Laszlo
>>>
>>> Laszlo Ersek (3):
>>>  BaseTools/header.makefile: add "-Wno-stringop-truncation"
>>>  BaseTools/header.makefile: add "-Wno-restrict"
>>>  BaseTools/GenVtf: silence false "stringop-overflow" warning with
>>>    memcpy()
>>>
>>> BaseTools/Source/C/Makefiles/header.makefile | 4 ++--
>>> BaseTools/Source/C/GenVtf/GenVtf.c           | 4 ++--
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> --
>>> 2.14.1.3.gb7cf6e02401b
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Ard Biesheuvel]

On 7 March 2018 at 09:11, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/07/18 07:43, Gao, Liming wrote:
>> Laszlo:
>>   We just find this change causes XCODE5 build failure, because XCODE compiler doesn't know these two options. So, could you provide the patch to remove the change in BUILD_CFLAGS for MAC?
>
> Yep, I was a bit concerned about that.
>
> Ultimately I assumed that
> - clang would either recognize these warnings options (because it does
>   recognize most -W options of gcc),
> - or, similarly to gcc, clang would simply ignore -Wno-* flags that it
>   does not recognize.
>
> Neither appears to be the case, then. I'll send a patch soon.
>

What is the reason we don't pass -Wno-unknown-warning-option to XCODE ?

Re: [PATCH 0/3] BaseTools: let the C-language build utils compile with gcc-8

[Laszlo Ersek]

On 03/07/18 10:12, Ard Biesheuvel wrote:
> On 7 March 2018 at 09:11, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 03/07/18 07:43, Gao, Liming wrote:
>>> Laszlo:
>>>   We just find this change causes XCODE5 build failure, because XCODE compiler doesn't know these two options. So, could you provide the patch to remove the change in BUILD_CFLAGS for MAC?
>>
>> Yep, I was a bit concerned about that.
>>
>> Ultimately I assumed that
>> - clang would either recognize these warnings options (because it does
>>   recognize most -W options of gcc),
>> - or, similarly to gcc, clang would simply ignore -Wno-* flags that it
>>   does not recognize.
>>
>> Neither appears to be the case, then. I'll send a patch soon.
>>
> 
> What is the reason we don't pass -Wno-unknown-warning-option to XCODE ?

My personal reason is that I simply didn't think of
"-Wno-unknown-warning-option", for either XCODE or GCC. I just added the
two new -Wno-xxx options to the GCC command line, tested them with
gcc-4.8 (which knows neither of those options), and gcc-4.8 didn't
complain, without needing any further massaging from my side. I assumed
"ignore unknown -Wno-xxx options" was the default (vaguely recalling
something like this from an earlier patch of yours -- apparently
incorrectly?), and that the same would apply to XCODE too.

Thanks
Laszlo