This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: _Fract types and conversion routines
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, sellcey at imgtec dot com
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 30 Oct 2015 11:17:20 -0700
- Subject: Re: _Fract types and conversion routines
- Authentication-results: sourceware.org; auth=none
- References: <8ea17595-285a-4062-bb85-bf6d6a3b56e6 at BAMAIL02 dot ba dot imgtec dot org> <CAFiYyc0bG0J=ZxzoNTc18BmNKQnQQ9yb=SaMtixQ2nMv8Gj+dA at mail dot gmail dot com> <1446050092 dot 2982 dot 100 dot camel at ubuntu-sellcey> <1446050979 dot 2982 dot 106 dot camel at ubuntu-sellcey> <1446140989 dot 2982 dot 129 dot camel at ubuntu-sellcey> <CAFiYyc1S0MQNXjDifVkrSoXoHcO0-TyW7=Q=McDYHQLxMCKKSw at mail dot gmail dot com>
On 10/30/2015 02:05 AM, Richard Biener wrote:
> On Thu, Oct 29, 2015 at 6:49 PM, Steve Ellcey <sellcey@imgtec.com> wrote:
>> So should __satfractqiuhq be dealing with the fact that the argument 'a'
>> may not have been sign extend in the correct way?
>
> No. GCC should ensure libcalls (yes, they are speical for some non-obvious
> reason) always adhere to the platform ABI at the caller side.
>
> Not sure why the libcall path doesn't (well, I gues it doesn't) adhere
> to FUNCTION_VALUE and friends. History maybe (or maybe the
> idea to explicitely allow differing ABIs for those?)
History only.
We've talked about ditching libcalls entirely, but no one's gotten around to it
yet. It shouldn't be hard to auto-generate tree decls for the functions and go
through the normal expand_call.
r~