erichkeane added a comment. In D111778#3064439 <https://reviews.llvm.org/D111778#3064439>, @craig.topper wrote:
> In D111778#3064287 <https://reviews.llvm.org/D111778#3064287>, @FreddyYe > wrote: > >> In D111778#3063891 <https://reviews.llvm.org/D111778#3063891>, @erichkeane >> wrote: >> >>> Supporting these types requires changes to the library so that we can check >>> these, right? Do you have the library changes for these as well? The >>> constants used to check for these features/etc needs to be present in the >>> glibc library. >> >> Yes. It's highly related to the `ProcessorFeatures` I mentioned above. Does >> the `library changes` refer to the compiler-rt/cpu_model.c? I think that >> change depends on libgcc. For now libgcc has no strong will to update that >> table. > > Every feature gcc knows about should be in libgcc. The unfortunate problem > now is that cpu_features2 in libgcc is an array thats size may be different > with every version of gcc. Clang can’t know how big that array is without > reading the libgcc.a symbol table at compile time. Without knowing the size > we can’t access any bits past the first 32 bits of cpu_features2. libgcc entries are the ones I was concerned about. We need to make sure this list matches that one (and we don't generate checks that it does not have). @craig.topper can better clarify what needs to happen with the library lookup, but I THINK we keep a version of this in compiler-rt instead of using libgcc? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111778/new/ https://reviews.llvm.org/D111778 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
