Thanks, after checking the code, I think it might be a bug. Do you try to fix it? If not, I will fix it

Well I think a decent solution here would be to add a string attribute like no-jump-tables that just tells that function that changing stack protection levels on the caller is a no-no.

after checking the review, https://reviews.llvm.org/D91816, always_inline might be a special case for ssp and no-ssp

after checking the review, https://reviews.llvm.org/D91816, always_inline might be a special case for ssp and no-ssp

Hm, so this might be intended behavior?

might be cc @nickdesaulniers

yes, that's the intention, though @zmodem also brought up that maybe we should change this for always_inline (further weakening the "always" part of "always inline").

yes, that's the intention, though @zmodem also brought up that maybe we should change this for always_inline (further weakening the "always" part of "always inline").

I don't really know how I feel about this.. I'd rather have something marked always_inline be, well, inlined, without a stack protector; for example, if you have a set of performance-critical functions separated out to not duplicate code, or some thirdparty dependency that you expect to be inlined when using always_inline, behavior like this would very much subvert expectations. I don't know what the right answer is here, but either way the documentation for this should probably be very explicit.

yes, that's the intention, though @zmodem also brought up that maybe we should change this for always_inline (further weakening the "always" part of "always inline").

I don't really know how I feel about this.. I'd rather have something marked always_inline be, well, inlined, without a stack protector; for example, if you have a set of performance-critical functions separated out to not duplicate code, or some thirdparty dependency that you expect to be inlined when using always_inline, behavior like this would very much subvert expectations. I don't know what the right answer is here, but either way the documentation for this should probably be very explicit.

I will try to update the document in clang and try to connect with @nickdesaulniers .

(The discussion from Chromium is here: https://crbug.com/1274129)

My preference would be to not bring along the stack protector when inlining.

Taking a stab at this here: https://reviews.llvm.org/D116589

Taking a stab at this here: https://reviews.llvm.org/D116589

Committed as 2bc57d8.