On Tue, May 28, 2019 at 08:10:19AM -0700, H.J. Lu wrote:
> On Tue, May 28, 2019 at 1:57 AM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Sat, Feb 16, 2019 at 07:02:11AM -0800, H.J. Lu wrote:
> > > > For NOTE_INSN_DELETED_LABEL, we should check if forced_labels to see
> > > > if its address is taken. Also ix86_init_large_pic_reg shouldn't set
> > > > LABEL_PRESERVE_P (in_struct) since NOTE_INSN_DELETED_LABEL is suffcient
> > > > to keep the label.
> >
> > Can you explain when is it ever needed to emit ENDBR on
> > NOTE_INSN_DELETED_LABEL? Only labels that are proven not to be ever
> > branched to are turned into deleted labels, so I think the right answer is
> > never emit any ENDBR on those...
> >
>
> This condition is checked by gcc.target/i386/cet-label-5.c in the
> patch. For
>
> void *
> func (void)
> {
> return &&bar;
> bar:
> return 0;
> }
>
> we generate:
>
> (note/s 4 2 10 2 ("bar") NOTE_INSN_DELETED_LABEL 2)
> (insn:TI 10 4 11 2 (set (reg/i:DI 0 ax)
> (label_ref:DI [4 deleted]))
> "/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/cet-label-5.c":13:1
> 66 {*movdi_internal}
> (nil))
> (insn 11 10 20 2 (use (reg/i:DI 0 ax))
> "/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/cet-label-5.c":13:1
> -1
> (nil))
We shouldn't generate ENDBR in that case, nothing can goto to bar (otherwise
it would remain a normal label, not a deleted label).
Jakub
