https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |trippels at gcc dot gnu.org
--- Comment #11 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Denis Vlasenko from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > If you expect that all functions with inline keyword must be always inlined,
> > then you really should use __always_inline__ attribute. Otherwise, inline
> > keyword is primarily an optimization hint to the compiler that it might be
> > desirable to inline it. So, talking about uninlining or deinlining makes
> > absolutely no sense,
>
> Jakub, are you saying that compiling
>
> static inline oid spin_unlock(spinlock_t *lock)
> {
> __raw_spin_unlock(&lock->rlock);
> }
>
> , where __raw_spin_unlock is a function (not macro), to a deinlined function
>
> spin_unlock:
> call __raw_spin_unlock
> ret
>
>
> and then callers doing
>
> call spin_unlock
>
> *can ever* make sense? That's ridiculous.
>
>
> How about this?
>
> static inline void atomic_inc(atomic_t *v)
> {
> asm volatile(LOCK_PREFIX "incl %0"
> : "+m" (v->counter));
> }
>
> You think it's okay to not inline one insn?
>
>
> Kernel people did not take my patch which tries to fix this by
> __always_inining locking ops.
That is their problem then. Every other sane project uses __always_inline for
this issue.
> Basically, they think that compiler should not do stupid things.
The compiler isn't psychic, e.g. it doesn't parse asm statements at all (so
it cannot know how many insn it contains).
