On 13 April 2017 at 09:55, Ramana Radhakrishnan
wrote:
> On Wed, Apr 12, 2017 at 6:55 PM, Christophe Lyon
> wrote:
>> Hi,
>>
>> It looks like we forgot to backport the fix for PR68390 to gcc-5-branch.
>> The patch applies cleanly, and fwiw we've had it in the linaro-5
>> branch for a while.
>>
>>
On Wed, Apr 12, 2017 at 6:55 PM, Christophe Lyon
wrote:
> Hi,
>
> It looks like we forgot to backport the fix for PR68390 to gcc-5-branch.
> The patch applies cleanly, and fwiw we've had it in the linaro-5
> branch for a while.
>
> OK to apply to gcc-5-branch?
>
OK if there are no regressions (th
Hi,
It looks like we forgot to backport the fix for PR68390 to gcc-5-branch.
The patch applies cleanly, and fwiw we've had it in the linaro-5
branch for a while.
OK to apply to gcc-5-branch?
Thanks,
Christophe
2017-04-12 Christophe Lyon
Backport from mainline
+2015-11-23 Ku
This issue also remains in 4.9 and 5.0 branches. Is this OK to backport
to the release branches.
Thanks,
Kugan
On 02/12/15 10:00, Kugan wrote:
>
>>>
>>> gcc/ChangeLog:
>>>
>>> 2015-11-18 Kugan Vivekanandarajah
>>>
>>> PR target/68390
>>> * config/arm/arm.c (arm_function_ok_for_sibcal
>>
>> gcc/ChangeLog:
>>
>> 2015-11-18 Kugan Vivekanandarajah
>>
>> PR target/68390
>> * config/arm/arm.c (arm_function_ok_for_sibcall): Get function type
>> for indirect function call.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2015-11-18 Kugan Vivekanandarajah
>>
>> PR target/
On 18/11/15 00:32, Kugan wrote:
>> > Hi Ramana,
>> >
>> > Thanks for the review. I have opened a gcc bug-report for this. I tested
>> > the attached patch for arm-none-linux-gnueabihf and
>> > arm-none-linux-gnueabi with no new regressions. Is this OK?
>> >
>> >
>> > Thanks,
>> > Kugan
>> >
>>
> Hi Ramana,
>
> Thanks for the review. I have opened a gcc bug-report for this. I tested
> the attached patch for arm-none-linux-gnueabihf and
> arm-none-linux-gnueabi with no new regressions. Is this OK?
>
>
> Thanks,
> Kugan
>
> gcc/ChangeLog:
>
> 2015-11-18 Kugan Vivekanandarajah
>
>
On 17/11/15 21:05, Ramana Radhakrishnan wrote:
> Hi Kugan,
>
> It does look like an issue.
>
> Please open a bug report.
>
>>
>>
>> On 17/11/15 12:00, Charles Baylis wrote:
>>> On 16 November 2015 at 22:24, Kugan
>>> wrote:
>>>
Please note that we have a sibcall from "broken" to "indire
Hi Kugan,
It does look like an issue.
Please open a bug report.
>
>
> On 17/11/15 12:00, Charles Baylis wrote:
>> On 16 November 2015 at 22:24, Kugan
>> wrote:
>>
>>> Please note that we have a sibcall from "broken" to "indirect".
>>>
>>> "direct" is variadic function so it is conforming to
On 17/11/15 12:00, Charles Baylis wrote:
> On 16 November 2015 at 22:24, Kugan wrote:
>
>> Please note that we have a sibcall from "broken" to "indirect".
>>
>> "direct" is variadic function so it is conforming to AAPCS base standard.
>>
>> "broken" is a non-variadic function and will return th
On 17/11/15 12:00, Charles Baylis wrote:
> On 16 November 2015 at 22:24, Kugan wrote:
>
>> Please note that we have a sibcall from "broken" to "indirect".
>>
>> "direct" is variadic function so it is conforming to AAPCS base standard.
>>
>> "broken" is a non-variadic function and will return th
On 16 November 2015 at 22:24, Kugan wrote:
> Please note that we have a sibcall from "broken" to "indirect".
>
> "direct" is variadic function so it is conforming to AAPCS base standard.
>
> "broken" is a non-variadic function and will return the value in
> floating point register for TARGET_HARD
Following testcase fails on ARM (from
https://bugs.linaro.org/show_bug.cgi?id=1900).
__attribute__ ((noinline))
double direct(int x, ...)
{
return x*x;
}
__attribute__ ((noinline))
double broken(double (*indirect)(int x, ...), int v)
{
return indirect(v);
}
int main ()
{
double d1, d2;
i
13 matches
Mail list logo
