Hi! On Thu, 19 Feb 2015 14:09:29 +0100, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Feb 17, 2015 at 09:55:32PM +0100, Bernd Schmidt wrote: > > On 02/17/2015 06:10 PM, Jakub Jelinek wrote: > > > > > >What exact testcase are you trying to fix with this patch, and how do you > > >think offloading of code using va_list can work? > > > > The exact testcase is any offloaded program - streaming in lto will crash if > > there is a mismatch in these preloaded nodes.
> could following untested patch be used as a temporary hack? Thanks! I'll leave the approval to Bernd, but can already report that this works fine in my testing, for intelmic and nvptx offloading. > It might pessimize for GCC5 slightly the intelmic offloading, but I hope > the way forward is the stdarg late lowering for GCC 6. > Richard on IRC said it might be better for the lto_stream_offload_p > path to whitelist nodes it has to preload rather than blacklist the ones > that it doesn't, otherwise e.g. if you try to offload from say x86_64-mingw > with 32-bit long, but 64-bit pointers to 64-bit intelmic That's a good consideration (for the future), but we're not currently supporting the case of offloading with non-matching ABIs (data types). > preloading > the long_type_node will certainly break lots of things, while not preloading > them would only be problematic for builtins, we'll need some pass over the > builtins in the IL in any case, to find out if they are compatible or not, > adjust if needed and give up otherwise. But I'd hope it can be worked on > incrementally, if this patch (plus the approved nvptx offloading patches, > plus mode_table streaming) makes the nvptx offloading work. Grüße, Thomas
pgpGNGSrsRKJ6.pgp
Description: PGP signature
