On June 8, 2017 5:40:06 PM GMT+02:00, Tamar Christina <tamar.christ...@arm.com>
wrote:
>The testcase does something unexpected
>
>extern "C" int isnan ();
>
>void foo(float a) {
> int (*xx)(...);
> xx = isnan;
> if (xx(a))
> g++;
>}
>
>and I'm wondering if this is a valid thing to do with a builtin. The
>issue is that at the point where gimple lowering is done xx hasn't been
>resolved to isnan yet.
>So it never recognizes the alias. Previously these builtins were being
>resolved in expand, which happens late enough that it has replaced xx
>with isnan.
>
>I can obviously fix the ICE by having the expand code leave the call as
>a call instead of a builtin. But if this is a valid thing for a builtin
>i'm not sure how to
>best resolve this case.
For a built-in this is generally valid. For plain isnan it depends on what the
standard says.
You have to support taking the address of isnan anyway and thus expanding to a
library call in that case. Why doesn't that not work?
Richard.
>________________________________________
>From: Tamar Christina
>Sent: Thursday, June 8, 2017 1:21:44 PM
>To: Christophe Lyon; Markus Trippelsdorf
>Cc: Joseph Myers; Jeff Law; GCC Patches; Wilco Dijkstra;
>rguent...@suse.de; Michael Meissner; nd
>Subject: RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
>numbers in GIMPLE.
>
>Thanks, I'm looking at the failure.
>My final validate seems to have only run the GCC tests.
>
>> -----Original Message-----
>> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
>> Sent: 08 June 2017 13:00
>> To: Markus Trippelsdorf
>> Cc: Joseph Myers; Tamar Christina; Jeff Law; GCC Patches; Wilco
>Dijkstra;
>> rguent...@suse.de; Michael Meissner; nd
>> Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
>> numbers in GIMPLE.
>>
>> On 8 June 2017 at 12:30, Markus Trippelsdorf <mar...@trippelsdorf.de>
>> wrote:
>> > On 2017.01.19 at 18:20 +0000, Joseph Myers wrote:
>> >> On Thu, 19 Jan 2017, Tamar Christina wrote:
>> >>
>> >> > Hi Joseph,
>> >> >
>> >> > I made the requested changes and did a quick pass over the rest
>of
>> >> > the fp cases.
>> >>
>> >> I've no further comments, but watch out for any related test
>failures
>> >> being reported.
>> >
>> > g++.dg/opt/pr60849.C started ICEing on both X86_64 and ppc64le.
>> >
>>
>> Same on arm/aarch64, but there are also other regressions on
>big-endian
>> configs:
>> See http://people.linaro.org/~christophe.lyon/cross-
>> validation/gcc/trunk/249005/report-build-info.html
>>
>>
>> > --
>> > Markus
