This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1/3] optabs: introduce {SET_,}{CONVERT_,}OPTAB_HANDLER

On Sat, Jul 3, 2010 at 11:11 PM, Manuel López-Ibáñez
<> wrote:
> On 3 July 2010 23:07, Steven Bosscher <> wrote:
>> On Sat, Jul 3, 2010 at 10:38 PM, Diego Novillo <> wrote:
>>> On Saturday, July 3, 2010, Richard Sandiford <> wrote:
>>>> I wondered about that, and not having a strong feeling either way,
>>>> decided to stick with the current macro idiom. ?Can change if you like.
>>> Yes, please. ?I would like to eliminate most of the function-like
>>> macros we have. ?Let the inliner do its job and improve debuggability
>>> by being able to set proper breakpoints.
>> ... and force us to include headers that exposes things that should
>> not be exposed. See e.g. all GIMPLE static inlines, which force us to
>> expose the GIMPLE data structures also. And here the obtabs internals
>> to files that only use obtabs.
> Why would this be different when using macros?

Nothing. Just a point against eliminating macros in favor of static
inline functions in general.

I'd argue for functions not static inline, in a .c file, and _really_
let the inliner do its job (with WHOPR).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]