On Tue, May 28, 2019 at 10:33 AM Jeff Law wrote: > > On 5/28/19 9:48 AM, Jakub Jelinek wrote: > > On Tue, May 28, 2019 at 08:30:59AM -0700, H.J. Lu wrote: > >>> We shouldn't generate ENDBR in that case, nothing can goto to bar (otherwise > >>> it would remain a normal label, not a deleted label). > >>> > >> > >> But return value of func () may be used with indirect jump. > > > > No, it may be used say to print that address, but computed goto can't be > > used to jump from one function to a different function, see > > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html > > "You may not use this mechanism to jump to code in a different function. > > If you do that, totally unpredictable things happen." > Right. We disallowed this case some time ago IIRC. It's essentially > undefined behavior. I would even claim that in a CET world that we > *want* a CET fault if something tried to use the deleted label as a jump > target and thus an ENDBR is undesirable. > > > > > > NOTE_INSN_DELETED_LABEL is not guaranteed to be followed by any sensible > > code, the only reason it is kept is that there is or might be something > > referencing the label and so you want to emit the label somewhere in the > > function, but don't care much where in the function. > Exactly. > > Jeff Here is the updated patch not to insert ENDBR after NOTE_INSN_DELETED_LABEL. Tested on Linux/x86-64 with -fcf-protection. OK for trunk? Thanks. -- H.J.