On 01/29/16 02:48, Richard Biener wrote:
I see. Is it possible to simply scrub the whole OACC region in this
case instead?
Do you mean jettison the body of the offloaded fn, or something else? I guess
the former's doable. (Throwing away the fn entirely could result in unresolved
symbol
On Thu, Jan 28, 2016 at 6:49 PM, Tom de Vries wrote:
> On 28/01/16 14:32, Richard Biener wrote:
>>
>> On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries
>> wrote:
>>>
>>> On 14/01/16 10:43, Richard Biener wrote:
On Wed, Jan 13, 2016 at
On 28/01/16 14:32, Richard Biener wrote:
On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries wrote:
On 14/01/16 10:43, Richard Biener wrote:
On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries
wrote:
Hi,
At r231739, there was an ICE when checking code
On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries wrote:
> On 14/01/16 10:43, Richard Biener wrote:
>>
>> On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries
>> wrote:
>>>
>>> Hi,
>>>
>>> At r231739, there was an ICE when checking code generated by
>>>
On 14/01/16 10:43, Richard Biener wrote:
On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries wrote:
Hi,
At r231739, there was an ICE when checking code generated by
oacc_xform_loop, in case the source contained an error.
Due to seen_error (), gimplification during
On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries wrote:
> Hi,
>
> At r231739, there was an ICE when checking code generated by
> oacc_xform_loop, in case the source contained an error.
>
> Due to seen_error (), gimplification during oacc_xform_loop bailed out, and
> an
Hi,
At r231739, there was an ICE when checking code generated by
oacc_xform_loop, in case the source contained an error.
Due to seen_error (), gimplification during oacc_xform_loop bailed out,
and an uninitialized var was introduced. Because of gimplifying in ssa
mode, that caused an ICE.