> On Oct 9, 2019, at 7:44 AM, Gao, Liming <liming....@intel.com> wrote:
>
> Laszlo:
>
>> -----Original Message-----
>> From: Laszlo Ersek <ler...@redhat.com>
>> Sent: Wednesday, October 9, 2019 9:44 PM
>> To: Andrew Fish <af...@apple.com>; devel@edk2.groups.io
>> Cc: Gao, Liming <liming....@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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#48665): https://edk2.groups.io/g/devel/message/48665
Mute This Topic: https://groups.io/mt/34464936/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
