On Oct 9, 2019, at 7:44 AM, Gao, Liming <liming.gao@intel.com> wrote:

Laszlo:

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Wednesday, October 9, 2019 9:44 PM
To: Andrew Fish <afish@apple.com>; devel@edk2.groups.io
Cc: Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain

On 10/09/19 01:08, Andrew Fish wrote:

So I guess the way to describe it is XCODE inherits GCC and only needs to override when it is different.

Thank you for the explanation!

I've been trying to figure out why this inheritance bothers me so much.
I guess the reason is the following:

I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, GCC5).
Assume that I realize that a gcc-specific change is needed to some part
of the code. (It could be build options, or gcc specific source code,
etc.) Then, I go to the gcc documentation, and verify whether the change
is indeed supported by all the relevant gcc versions.

If the change is possible with only some gcc versions, then I likely
write the change for a specific toolchain only, such as GCC5. Fine.

Now assume that my documentation review proves that *all* GCCxx
toolchains, supported by edk2, should receive the update. This could be
a #pragma, a command line flag, some __attribute__, etc. I'd very likely
express the change for the whole GCC toolchain *family*, and not
enumerate it for GCC48, GCC49, GCC5 individually.

And now I learn that said approach would be wrong, because such a change
would be inherited by XCODExx and CLANGxx too (via FAMILY), fully
against my intent, unless XCODExx and CLANGxx overrode the particular
aspect (via BUILDRULEFAMILY).

The difference between XCODE/CLANG and GCCXX is the linker. Current patches are
introduced for the different linker. Clang supports most usage of GCC compiler.
So, CLANG and XCODE uses GCC family. When I enable XCODE or CLANG tool chain
in the platform, I don't find other incompatible behavior with GCC compiler.
So, I think it is safe to let CLANG inherit GCC option except for these two cases.
When you make new changes, and verify them with GCC compiler, that's enough.
You don't need to specially verify them with XCODE or CLANG. In most case, GCC
compiler pass, XCODE or CLANG can also pass.

Liming,

I agree that clang attempts to be drop in compatible with GCC and the big difference is the linker. For the most part XCODE means macOS linker + clang.

I thought the thing we were discussing was compiler flags. Specifically -mno-mmx -mno-sse. It seems to me if OVMF requires -mno-mmx -mno-sse then it is a bug in the tools_def.txt definition for those compilers? As far as I can tell -mno-implicit-float should prevent the optimizer from using floating point. The -mno-mmx -mno-sse flags most change how floating point code gets compiled [1]. it looks like -mno-mmx -mno-sse just down grade floating point instructions that get used. Thus it seems like either we have some code doing float and that code should set -mno-mmx -mno-sse, or the -mno-mmx -mno-sse should be set generically.

[1]

~/work/Compiler/float>cat c.c

int main()

{

    float a = 10;

    float b = 20;

    float c = a * b;

    return 0;

}

~/work/Compiler/float>clang -S c.c -mno-implicit-float

~/work/Compiler/float>cat c.S

	.section	__TEXT,__text,regular,pure_instructions

	.build_version macos, 10, 15	sdk_version 10, 15

	.section	__TEXT,__literal4,4byte_literals

	.p2align	2               ## -- Begin function main

LCPI0_0:

	.long	1101004800              ## float 20

LCPI0_1:

	.long	1092616192              ## float 10

	.section	__TEXT,__text,regular,pure_instructions

	.globl	_main

	.p2align	4, 0x90

_main:                                  ## @main

	.cfi_startproc

## %bb.0:

	pushq	%rbp

	.cfi_def_cfa_offset 16

	.cfi_offset %rbp, -16

	movq	%rsp, %rbp

	.cfi_def_cfa_register %rbp

	xorl	%eax, %eax

	movss	LCPI0_0(%rip), %xmm0    ## xmm0 = mem[0],zero,zero,zero

	movss	LCPI0_1(%rip), %xmm1    ## xmm1 = mem[0],zero,zero,zero

	movl	$0, -4(%rbp)

	movss	%xmm1, -8(%rbp)

	movss	%xmm0, -12(%rbp)

	movss	-8(%rbp), %xmm0         ## xmm0 = mem[0],zero,zero,zero

	mulss	-12(%rbp), %xmm0

	movss	%xmm0, -16(%rbp)

	popq	%rbp

	retq

	.cfi_endproc

                                        ## -- End function

.subsections_via_symbols

~/work/Compiler/float>clang -S c.c -mno-implicit-float -mno-mmx -mno-sse

~/work/Compiler/float>cat c.S

	.section	__TEXT,__text,regular,pure_instructions

	.build_version macos, 10, 15	sdk_version 10, 15

	.globl	_main                   ## -- Begin function main

	.p2align	4, 0x90

_main:                                  ## @main

	.cfi_startproc

## %bb.0:

	pushq	%rbp

	.cfi_def_cfa_offset 16

	.cfi_offset %rbp, -16

	movq	%rsp, %rbp

	.cfi_def_cfa_register %rbp

	xorl	%eax, %eax

	movl	$0, -4(%rbp)

	movl	$1092616192, -8(%rbp)   ## imm = 0x41200000

	movl	$1101004800, -12(%rbp)  ## imm = 0x41A00000

	flds	-8(%rbp)

	flds	-12(%rbp)

	fmulp	%st(1)

	fstps	-16(%rbp)

	popq	%rbp

	retq

	.cfi_endproc

                                        ## -- End function

.subsections_via_symbols

~/work/Compiler/float>

Thanks,

Andrew Fish

Thanks
Liming

This means that, after checking the gcc documentation meticulously
(multiple releases), and possibly even testing multiple gcc
installations, I could still regress edk2 (CLANGxx and/or XCODExx
specific parts), because they could inherit my GCC-oriented changes that
I never meant for CLANGxx and/or XCODExx.

I don't use XCODE or CLANG, I don't test on them, and now it seems I can
restrict changes to the *actual* gcc compilers only if I keep spelling
out the individual toolchain names, such as GCC48, GCC49, GCC5.

This makes the toolchain family concept totally useless to me (and to
other users that only care about actual gcc compilers). There is no
*family* facility available that allows people to restrict settings to
actual gcc compilers. In other words, we can't express "all GCCxx
toolchains, regardless of toolchain version, but not XCODE, and also not
CLANG".

Thanks
Laszlo