This is the mail archive of the
mailing list for the GCC project.
Re: Debugging offload compiler ICEs
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 3 May 2016 13:30:30 +0200
- Subject: Re: Debugging offload compiler ICEs
- Authentication-results: sourceware.org; auth=none
- References: <87h9efwh7u dot fsf at kepler dot schwinge dot homeip dot net> <CAFiYyc2Vh+j5DA2LWadOMzBDMVUOrChuma0DKW1piQM7LrB7ew at mail dot gmail dot com> <87oa8nxub9 dot fsf at hertz dot schwinge dot homeip dot net>
On Tue, May 3, 2016 at 1:19 PM, Thomas Schwinge <firstname.lastname@example.org> wrote:
> On Tue, 3 May 2016 12:54:23 +0200, Richard Biener <email@example.com> wrote:
>> On Tue, May 3, 2016 at 12:47 PM, Thomas Schwinge
>> <firstname.lastname@example.org> wrote:
>> > It is currently difficult to debug offloading compiler invocations.
>> > These are actually lto1 front ends invoked from the target compilation's
>> > collect2 process, via the respective offloading toolchain's mkoffload.
>> Does -v -save-temps not provide enough info to re-launch the lto1 process?
> Actually, given very limited testing I have just done, that indeed seems
> to work fine now, for re-running the actual offload compiler invocation
> (driver as well as lto1 directly). Good! (As far as I remember, it used
> not to work a few months ago, with relevant files not having been
> preserved; that's where I got the idea from for this "pause" hack.) To
> re-run the mkoffload invoked before, you'll need to set (several?)
> environment variables.
Yeah, for example debugging things like lto-wrapper itself that is also
required. But cut&pasting the lto1 command should work (if not we should