This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fobey-inline (was Re: gcc and inlining)
On Thu, Mar 13, 2003 at 03:19:45PM +0100, Lars Segerlund wrote:
>
> Please, this is getting tiresome, I agree with Steven, this is needed,
> otherwise it'll be a case of 'you can't build a linux kernel without a
> patch to gcc'
>
> If this is not working or any similar mechanism, it will make those of
> us using this sort of functionality bear the burden of replacing large
> sections of code with macros.
>
> It has been repeatedly requested, and surely it's not resonable to
> argue with fx. kernel developers who says thar they REALLY need this ?
For the record, the kernel doesn't need this any more. Go check 2.5;
new versions of <linux/compiler.h> contain this line:
#define inline __inline__ __attribute__((always_inline))
Which should accomplish the same thing.
(That said, I still think -fobey-inline is a reasonable thing to
support.)
>
> Are there any arguments against this other than ideological ? ( this
> flag doesn't interfere with gcc's normal operation and only when it's
> needed is it in effect, how can that be so bad ? ).
>
> / Lars Segerlund.
>
> Richard Earnshaw wrote:
> >>Richard Earnshaw writes:
> >>> >
> >>> > -fobey-inline is more of a correctness issue than a performance issue
> >>> > for the people who need it.
> >>>
> >>> No, it's a compile my buggy program issue.
> >>>
> >>> There is no guarantee in the standard that an "inline" function will be
> >>> inlined.
> >>
> >>Yes, but there are places where being able to guarantee inlining are
> >>very useful. glibc has one in the shared library loader, and there
> >>are places in a kernel where it is essential to inline (perhaps
> >>because there is no stack) but people are forced to use macros if
> >>inlining is not guaranteed. macros are bad for a bunch of reasons,
> >>not the least of which is type safety.
> >>
> >
> >
> >And we have an attribute (always_inline) for that case. We don't need
> >another method as well.
> >
> >R.
> >
> >
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer