[cfe-dev] Warning for partially implemented options/pragmas?

Fri May 29 03:18:39 PDT 2020

Hi Kevin,
Do you have any updates on this?
Have you proposed a patch on Phabricator perhaps?

On Fri., Apr. 24, 2020, 12:47 p.m. Kevin Neal, <Kevin.Neal at sas.com> wrote:

> Oh, I can see that. We’ve got an intern that’s been testing as well.
>
>
>
> I wouldn’t oppose you adding that option. I don’t know what anyone else
> thinks, though.
>
>
>
> Right now my problem is I know very little about clang’s driver. So that’s
> where I’m working at the moment.
>
> --
> Kevin P. Neal
> SAS/C and SAS/C++ Compiler
>
> Compute Services
>
> SAS Institute, Inc.
>
>
>
>
>
>
>
> *From:* Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
> *Sent:* Friday, April 24, 2020 6:38 AM
> *To:* Kevin Neal <Kevin.Neal at sas.com>
> *Cc:* cameron.mcinally at nyu.edu; Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Warning for partially implemented
> options/pragmas?
>
>
>
> *EXTERNAL*
>
> The reason I suggested developer options was so that back end developers
> can build large applications using the option to get the intrinsics emitted
> and then chase what falls out (without changing the front end).
>
> For example, on PPC, I could specify the option, build the application
> that we know causes crashes in the back end for us and continue the work to
> implement full support.
>
>
>
> But as you mentioned, the changes in the front end to flip the flag to say
> PPC supports this and continue my testing would be trivial.
>
>
>
> On Thu, Apr 23, 2020 at 1:53 PM Kevin Neal <Kevin.Neal at sas.com> wrote:
>
> I’m already working on support for target-specific handling.
>
>
>
> I like the idea of target-specific disabling of the relevant options. I do
> think a warning is appropriate since this is a _*correctness*_ issue, and
> also because the options can be triggered indirectly like Cameron showed.
>
>
>
> The target-specific parts in clang itself that need to be done are very
> small, and as far as I know are confined to CGBuiltins.cpp. So I don’t
> think that any new options need to be added for developer use. Testing is
> an issue, but X86 and SystemZ are in such good shape that clang tests for
> anything else besides builtins can test on one of those two targets.
>
>
>
> *From:* Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
> *Sent:* Thursday, April 23, 2020 10:01 AM
> *To:* cameron.mcinally at nyu.edu
> *Cc:* Kevin Neal <Kevin.Neal at sas.com>; Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Warning for partially implemented
> options/pragmas?
>
>
>
> *EXTERNAL*
>
> I think it would be quite useful to add this in the front end. The way I
> envision this working is that targets would specify whether they support
> constrained FP intrinsics. If this flag is unset, it would cause the front
> end to do two things:
>
> 1. Warn the user that the mode is not supported for the target
>
> 2. Ignore the option and not generate the constrained FP intrinsics
>
>
>
> This should additionally be coupled with a temporary option for developers
> to use to aid in developing support for the intrinsics.
>
> Something like: -ftrapping-math-on-unsupported-target and
> -frounding-math-on-unsupported-target.
>
>
>
>
>
> On Thu, Apr 16, 2020 at 4:19 PM Cameron McInally via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> On Thu, Apr 16, 2020 at 4:01 PM Kevin Neal via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > Bug 45329 “segfault with frounding-math” “
> https://bugs.llvm.org/show_bug.cgi?id=45329
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.llvm.org%2Fshow_bug.cgi%3Fid%3D45329&data=02%7C01%7CKevin.Neal%40sas.com%7Cab254f4e50d7424ca62108d7e83b91d0%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637233214861132931&sdata=pcIeJcNeRtL0yyslM63lwyzf5Gfz%2B1oP8Lnytqv10G4%3D&reserved=0>”
> highlights that we are silently allowing people to use options that are
> unimplemented or only partially implemented.
> >
> > If use the -frounding-math option on a compile I expect it to work. I do
> not expect it to trigger an ICE, a crash, or much worse silently not work
> and produce wrong results.
> >
> > I propose a warning be printed so that we can avoid issues like bug
> 45329 in the future. And it needs to be per-target since some targets are
> closer to supporting this feature than others.
> >
> > Thoughts?
>
> Thanks for bringing this up, Kevin.
>
> We have a customer code that has been using
> `-fno-unsafe-math-optimizations` for some time. That option implies
> `-ftrapping-math`, which was a no-op until a few months ago. Now,
> `-ftrapping-math` enables the constrained FP intrinsics, which aren't
> fully supported on all targets. That behavior change looked like a
> regression to the customer.
>
> A warning would be a good short-term solution.
>
> -Cameron
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7CKevin.Neal%40sas.com%7Cab254f4e50d7424ca62108d7e83b91d0%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637233214861142923&sdata=kiBmCzsmtQmiw%2BlqezNJrXV6BWfi1JaUN9eA3%2FcPkG8%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200529/bda0ef13/attachment-0001.html>