On Fri, 15 Nov 2024 at 12:02, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Fri, Nov 15, 2024 at 11:25:00AM +0000, Jonathan Wakely wrote:
> > On Thu, 14 Nov 2024 at 18:16, Jan Hubicka <hubi...@ucw.cz> wrote:
> > >
> > > > Hi!
> > > >
> > > > The inlining heuristics uses DECL_DECLARED_INLINE_P (whether a function
> > > > has been explicitly marked inline; that can be inline keyword, or for
> > > > C++
> > > > also constexpr keyword or defining a function inside of a class
> > > > definition)
> > > > heavily to increase desirability of inlining a function etc.
> > > > In most cases it is desirable, people usually mark functions inline with
> > > > the intent that they are actually inlined.
> > >
> > > Reading the discussion on the PR, one of argument for adding new
> > > attribute was that we should not make differnece between "constexr" and
> > > "constexpr inline" since C++ stnadard says it is the same.
> > >
> > > We already do such difference between
> > >
> > > class foo
> > > {
> > > int bar () { }
> > > inline int bar2 () { }
> > > };
> >
> > We do?!?!
> >
> > Is this documented anywhere?
>
> As I wrote in another mail, the only difference I'm aware of is
> the DECL_NO_INLINE_WARNING_P flag, which is set on bar and not on bar2
> in this case. That flag is used just for -Winline warning.
>
> int baz (void *);
>
> struct S {
> int foo (int n) { return baz (__builtin_alloca (n)); }
> inline int bar (int n) { return baz (__builtin_alloca (n)); }
> };
>
> int
> baz (int n)
> {
> return S{}.foo (n) + S{}.bar (n);
> }
>
> We do warn with -O2 -Winline about not inlining bar, but not foo.
> This was changed in PR18071.
Which was about -fno-default-inline which was removed in 2013. So I
think it's a bug that -Winline still treats S::foo and S::bar
differently.
