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: [PATCH 2/4 v2] libcpp: Replace macro usage with C++ constructs)

> On 05/05/2015 12:21 PM, David Malcolm wrote:
> >On Mon, 2015-05-04 at 13:15 -0600, Jeff Law wrote:
> >On 05/01/2015 06:56 PM, David Malcolm wrote:
> >>>
> >>>[I didn't mark the inline functions as "static"; should they be?]
> Just a follow-up on this.  I got burned by the ODR issues around
> implicit extern inlines earlier this week.  Basically I had two
> distinct implementations for an inline function with the same name.
> They obviously appeared in different "header files".
> When optimizng, this was fine as they'd actually get inlined and all
> was good.  Things blew up when the optimizer was off.  We got two
> functions with the same name, but different implementations.  The
> linker blindly chose one for me, and in one context it was the wrong
> one.
> This led to bootstrap comparison failures.
> So, just be careful :-)

Martin actually tried using ICF to warn about such cases at LTO time (if the
two COMDAT function bodies does not seem to have same implementation, complain
about it). One showstopper here is that early inliner may divere easily (if you
provide inline implementation of called function in one unit), but perhaps we could
output warnings at least in cases we know that both optimization flags and
inline decisions match. (this can be checked during the compare by looking
at DECL_INITIAL block structure)

In GCC I would really love us to switch to non-static inline and just chase
out ODR violations if they exists (hopefully it is not that common). This
makes code reuse more explicit to IPA and hopefully will lead to smaller


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