llvm dev - Oct 2019 - PR43374 - when should comparing NaN values raise a floating point exception?

* Sanjay Patel <spatel at rotateright.com> [2019-10-08 08:07:10
-0400]:
> On Tue, Oct 8, 2019 at 7:08 AM Szabolcs Nagy <nsz at port70.net>
wrote:
> > why is that ok?
> >
> 
> Because there are no FP exceptions/signals for this IR opcode:
> http://llvm.org/docs/LangRef.html#floating-point-environment
so llvm cannot support an iso c frontend on an ieee754 target?
(or fortran for that matter)

On Tue, Oct 8, 2019 at 8:44 AM Szabolcs Nagy <nsz at port70.net> wrote:
> * Sanjay Patel <spatel at rotateright.com> [2019-10-08 08:07:10
-0400]:
> > On Tue, Oct 8, 2019 at 7:08 AM Szabolcs Nagy <nsz at port70.net>
wrote:
> > > why is that ok?
> > >
> >
> > Because there are no FP exceptions/signals for this IR opcode:
> > http://llvm.org/docs/LangRef.html#floating-point-environment
>
> so llvm cannot support an iso c frontend on an ieee754 target?
> (or fortran for that matter)
>
Not sure. I thought we solved the problems for all of the examples given so
far.
Do you have an end-to-end (C source to asm) example that shows a bug?
Please cite the C language law that is violated (add cfe-dev if there's a
front-end bug?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191008/61aa2d58/attachment.html>

* Sanjay Patel <spatel at rotateright.com> [2019-10-08 09:03:53
-0400]:
> On Tue, Oct 8, 2019 at 8:44 AM Szabolcs Nagy <nsz at port70.net>
wrote:
> 
> > * Sanjay Patel <spatel at rotateright.com> [2019-10-08 08:07:10
-0400]:
> > > On Tue, Oct 8, 2019 at 7:08 AM Szabolcs Nagy <nsz at
port70.net> wrote:
> > > > why is that ok?
> > > >
> > >
> > > Because there are no FP exceptions/signals for this IR opcode:
> > > http://llvm.org/docs/LangRef.html#floating-point-environment
> >
> > so llvm cannot support an iso c frontend on an ieee754 target?
> > (or fortran for that matter)
> >
> 
> Not sure. I thought we solved the problems for all of the examples given so
> far.
> Do you have an end-to-end (C source to asm) example that shows a bug?
> Please cite the C language law that is violated (add cfe-dev if there's
a
> front-end bug?).
anything that should observably raise a floating-point exception
does not work if llvm only provides silent operations or ignores
fenv side-effects during lowering, e.g.

#pragma STDC FENV_ACCESS ON
int cmp(float x, float y)
{
	return x < y;
}

is lowered to fcmp olt which you say should be silent:

define dso_local i32 @cmp(float %0, float %1) #0 {
  %3 = alloca float, align 4
  %4 = alloca float, align 4
  store float %0, float* %3, align 4
  store float %1, float* %4, align 4
  %5 = load float, float* %3, align 4
  %6 = load float, float* %4, align 4
  %7 = fcmp olt float %5, %6
  %8 = zext i1 %7 to i32
  ret i32 %8
}

this is observably non-iso c conform so clang miscompiles
math libraries written in c (math functions are required
to report errors by signaling floating-point exceptions).

it also does not support snan, but that's not strictly
required by iso c.