kristof.beyls added inline comments.
================ Comment at: llvm/docs/LangRef.rst:1659-1661 + that hardening. It should also be possible to *not* harden a hot and/or safe + function and have code inlined there *not* be hardened (even if the generic + form is hardened). ---------------- It feels wrong to me to have source code that is annotated to get hardened, but that actually will not get hardened (whether it is due to it being inlined somewhere or due to any other automatic behind-the-back-of-the-developer transformation). I fear this may lower trust in the protection this attribute provides. I assume there is a use case where the developer wants to indicate "no hardening in this function nor in any functions inlined here". If that needs to be supported, my feel is that we may need to support that in another way. I guess that there must be some cases where just duplicating the function to be inlined in the source code into a hardened and a non-hardened version could be too hard to do for some programs. So, in short, I don't know what the best solution here is. I just want to raise my concern that I don't think it's a good idea that functions that are marked to be hardened end up not getting hardened under some circumstances. Repository: rL LLVM https://reviews.llvm.org/D51157 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
