On Thu, Sep 17, 2015 at 08:06:48PM +0200, Bernd Edlinger wrote:
> Hi,
>
> On Thu, 17 Sep 2015 10:39:04, Jeff Law wrote:
> >
> > On 09/17/2015 09:00 AM, Marek Polacek wrote:
> >> On Wed, Sep 09, 2015 at 07:48:15PM +0200, Bernd Edlinger wrote:
> >>> Hi,
> >>>
> >>> On Wed, 9 Sep 2015 09:31:33, Jeff Law wrote:
> >>>> You could probably make the function static or change its visibility via
> >>>> a function attribute (there's a visibility attribute which can take the
> >>>> values default, hidden protected or internal). Default visibility
> >>>> essentially means the function can be overridden. I think changing it
> >>>> to "protected" might work. Note if we do that, we may need some kind of
> >>>> target selector on the test since not all targets support the various
> >>>> visibility attributes.
> >>>>
> >>>
> >>> Yes, it works both ways: static works, and __attribute__ ((visibility
> >>> ("protected"))) works too:
> >>>
> >>> make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c
> >>> --target_board='unix{-fpic,-mcmodel=medium,-fpic\
> >>> -mcmodel=medium,-mcmodel=large,-fpic\ -mcmodel=large}'"
> >>>
> >>> has all tests passed, but..
> >>>
> >>> make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c
> >>> --target_board='unix{-fno-inline}'"
> >>>
> >>> still fails in the same way for all workarounds: inline, static, and
> >>> __attribute__ ((visibility ("protected"))).
> >>>
> >>> Maybe "static" would be preferable?
> >>
> >> Yeah, I'd go with static if that helps. I'd rather avoid playing games
> >> with visibility.
> > Static is certainly easier and doesn't rely on targets implementing all
> > the visibility capabilities. So static is probably the best approach.
> >
>
> That's fine for me too, so is the original patch OK for trunk with
> s/inline/static/ ?
Yes.
Marek
