On Tue, May 28, 2019 at 8:16 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> 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).
>
But return value of func () may be used with indirect jump.
--
H.J.
