> On Oct 9, 2019, at 7:44 AM, Gao, Liming wrote: > > Laszlo: > >> -----Original Message----- >> From: Laszlo Ersek >> Sent: Wednesday, October 9, 2019 9:44 PM >> To: Andrew Fish ; devel@edk2.groups.io >> Cc: Gao, Liming >> 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