Hi!
On Thu, 28 Apr 2016 13:42:39 +0200, Bernd Schmidt wrote:
> On 04/28/2016 01:15 PM, Alexander Monakov wrote:
> > So if my understanding is correct, additional !cfun check can be acceptable
> > as
> > a fix along the existing hack. Perhaps with a note about the nature of the
> > hack.
>
> Ye
On 04/28/2016 01:15 PM, Alexander Monakov wrote:
So if my understanding is correct, additional !cfun check can be acceptable as
a fix along the existing hack. Perhaps with a note about the nature of the
hack.
Yes, I think Thomas' patch is ok.
Bernd
On Thu, 28 Apr 2016, Richard Biener wrote:
> Doing anything based on 'cfun' here is fishy at least for the
> call context of aggregate_value_p as that is also used when
> looking at the caller side of a call for example when expanding calls
> where cfun is then the callers cfun and not the callees.
On Thu, 28 Apr 2016, Thomas Schwinge wrote:
> Hi!
>
> Richard's r235511 changes (quoted below) cause certain nvptx offloading
> test cases to run into SIGSEGVs:
>
> [...]
> #4 0x00d14193 in nvptx_libcall_value (mode=mode@entry=SImode)
> at [...]/source-gcc/gcc/config/nvp
Hi!
Richard's r235511 changes (quoted below) cause certain nvptx offloading
test cases to run into SIGSEGVs:
[...]
#4 0x00d14193 in nvptx_libcall_value (mode=mode@entry=SImode)
at [...]/source-gcc/gcc/config/nvptx/nvptx.c:489
#5 0x00d17a20 in nvptx_function_v
