PanTao2 wrote: Thanks both. I'd like to go with (a): land this PR as it is, and do the metadata-only refactor afterwards. This PR fixes a real problem. clang-cl's default /GS currently protects far more functions than cl.exe does, because it maps onto -fstack-protector-strong. On my differential corpus this PR agrees with cl.exe 19.44 on 761 of 787 functions, versus 601 for the current behaviour. Of the 26 that differ: - 25 are caused by removing the sret rule, as requested in review. clang-cl protects them and cl.exe doesn't. - 1 is caused by a different inlining policy between clang and cl.exe, not a real difference in protection. @kubamracek, you offered to take the follow-up that marks every alloca in clang and removes the GS mode. I'd be glad if you did. The tests here compare against cl.exe's behaviour, so that refactor can show it changes nothing. Removing the mode also removes its inline-merge rule, since the metadata would be on each alloca. @nikic @efriedma-quic are you OK with landing this first on that basis?
https://github.com/llvm/llvm-project/pull/225626 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
