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/ ?

Thanks
Bernd.
                                          

Reply via email to