On 17 November 2016 at 11:27, Christophe Lyon
wrote:
> On 17 November 2016 at 10:53, Richard Biener wrote:
>> On Thu, 17 Nov 2016, Rainer Orth wrote:
>>
>>> Hi Richard,
>>>
>>> >> Probably providing dummy implemenations as in the original testcase in
>>> >> the PR is enough?
>>> >
>>> > Maybe { d
On 17 November 2016 at 10:53, Richard Biener wrote:
> On Thu, 17 Nov 2016, Rainer Orth wrote:
>
>> Hi Richard,
>>
>> >> Probably providing dummy implemenations as in the original testcase in
>> >> the PR is enough?
>> >
>> > Maybe { dg-require weak } plus weak definitions of the cyg_profile funcs?
On Thu, 17 Nov 2016, Rainer Orth wrote:
> Hi Richard,
>
> >> Probably providing dummy implemenations as in the original testcase in
> >> the PR is enough?
> >
> > Maybe { dg-require weak } plus weak definitions of the cyg_profile funcs?
> > Or simply restrict the test to { target *-*-linux* }?
>
Hi Richard,
>> Probably providing dummy implemenations as in the original testcase in
>> the PR is enough?
>
> Maybe { dg-require weak } plus weak definitions of the cyg_profile funcs?
> Or simply restrict the test to { target *-*-linux* }?
the only existing dg-do run testcase (gcc.dg/20001117-1.
On Thu, 17 Nov 2016, Rainer Orth wrote:
> Hi Christophe,
>
> > The new testcase fails to link on bare-metal targets (arm/aarch64):
> > /cc4ckSGA.o: In function `main':
> > pr78333.c:(.text+0x1c): undefined reference to `__cyg_profile_func_enter'
> > pr78333.c:(.text+0x34): undefined reference to
Hi Christophe,
> The new testcase fails to link on bare-metal targets (arm/aarch64):
> /cc4ckSGA.o: In function `main':
> pr78333.c:(.text+0x1c): undefined reference to `__cyg_profile_func_enter'
> pr78333.c:(.text+0x34): undefined reference to `__cyg_profile_func_exit'
> collect2: error: ld retur
On Thu, 17 Nov 2016, Christophe Lyon wrote:
> On 16 November 2016 at 10:35, Richard Biener wrote:
> >
> > Since GCC 4.6 we aggressively prune bodies of GNU extern inline functions
> > which means that instrumenting them via -finstrument-functions doesn't
> > work because that takes the address of
On 16 November 2016 at 10:35, Richard Biener wrote:
>
> Since GCC 4.6 we aggressively prune bodies of GNU extern inline functions
> which means that instrumenting them via -finstrument-functions doesn't
> work because that takes the address of the function. Fixed by not
> instrumenting those func
Since GCC 4.6 we aggressively prune bodies of GNU extern inline functions
which means that instrumenting them via -finstrument-functions doesn't
work because that takes the address of the function. Fixed by not
instrumenting those functions (we still instrument regular always-inline
functions and
