Re: [PATCH] Fix PR64078

[Tom de Vries <Tom_deVries@mentor.com>]

On 17/09/15 20:08, Marek Polacek wrote:
> 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.
>

Hi,

I've backported this fix to the 5 branch.

Thanks,
- Tom