This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations



> Am 20.08.2019 um 19:13 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
> 
> On Tue, Aug 20, 2019 at 06:13:00PM +0200, Ilya Leoshkevich wrote:
>>> Am 20.08.2019 um 17:50 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
>>> There is currently no way to say (in trees or gimple or rtl) whether
>>> comparisons are signaling ("ordered", generate a trap on an unordered
>>> result).  I am working on this, but :-)
>> 
>> Isn't there?  This whole series is based on the following assumption:
>> LT, LE, GT, GE are definitely signaling; LTGT is most likely signaling
>> as well; the rest are not signaling.  This is based on gccint 11.6.3:
>> Unary and Binary Expressions.
> 
> There is currently no way to implement, say, iseqsig.  And whether an
> operation is signaling should be determined by the language frontend,
> not separately by each backend!

Wouldn't expressing it as ((x <= y) && (x >= y)) work?

In any case, I'll need to check whether my patch series handles iseqsig
in at least remotely sane way..

> 
> (There should be a signaling and a non-signaling version of every float
> comparison that can be unordered).

I wholeheartedly agree.  I had to write quite a few ugly patterns to
work around the lack of e.g. non-signaling GT.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]