Hi,
> > I think the latter option is the right choice. The pain of preserving the > > ABI belongs with our hard-working branch maintainers (and they always have > > the option of rejecting a change because it would break the ABI). > > Absolutely! > > --renato > Sorry, I 'm not sure I'm following you guys correctly. Do you mean we should not allow any LLVMWhatever.so ABI broken, so we need to guarantee the ordering of those intrinsic enums generated by Intrinsicsxxx.td? If yes, I don't think it's worthwhile tuning them with whatever tricky method to make abi-compliance-checker give 100% backward compatibility, so I'd want to give up adding the complete NEON support in 3.4.1 release. Therefore, plan B is to port the followings to 3.4.1 release only, CLANG: 198940 Enable -fuse-init-array for all AArch64 ELF targets by default, not just linux. LLVM: 198937 Make sure -use-init-array has intended effect on all AArch64 ELF targets, not just linux. 198941 Silence unused variable warning for non-asserting builds that was introduced in r198937. 199369 For ARM, fix assertuib failures for some ld/st 3/4 instruction with wirteback. 201541 Fix a typo about lowering AArch64 va_copy. 201841 [AArch64] Add register constraints to avoid generating STLXR and STXR with unpredictable behavior. 204304 [ARM]Fix an assertion failure in A15SDOptimizer about DPair reg class by treating DPair as QPR. I tried them and the regression tests can all pass. -- Thanks, -Jiangning
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
