This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: nvptx offloading patches [2/n]
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 17 Feb 2015 18:10:01 +0100
- Subject: Re: nvptx offloading patches [2/n]
- Authentication-results: sourceware.org; auth=none
- References: <5454C944 dot 4090107 at codesourcery dot com> <20150204105554 dot GL1746 at tucnak dot redhat dot com> <CAFiYyc090-qas3vPUgLxQ_LHtZPvy5ee5NK3+BHPQLDVcBbfpA at mail dot gmail dot com> <54E36E30 dot 8040408 at codesourcery dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Feb 17, 2015 at 05:37:04PM +0100, Bernd Schmidt wrote:
> On 02/09/2015 11:16 AM, Richard Biener wrote:
>
> >Thus, if your patch survives LTO bootstrap and you can still LTO
> >a TU with ms_abi valist functions successfully (not sure if that's
> >exercised in the testsuite) then it is fine.
>
> I've now done the LTO bootstrap, and the program below compiled with -flto
> still works. Does that seem sufficient?
E.g. va_list_gpr_counter_field and va_list_fpr_counter_field are compared
for equality though, for va_list_type_node TYPE_MAIN_VARIANT is compared for
equality. Otherwise the stdarg pass might misbehave.
What exact testcase are you trying to fix with this patch, and how do you
think offloading of code using va_list can work?
Jakub