ping, looking for a code review, especially from front end folks. thank you!

I addressed some comments from @kpn: I corrected the documentation formatting and added some details, and used Diag instead of llvm_unreachable.

I added an inline reply and unmarked some things that had been inadvertently marked done.

I added documentation for the new floating point options into clang/docs

Here's a summary of how the rm and eb options are set

In D62731#1620174, @andrew.w.kaylor wrote:

I'm not entirely caught up on this review. I've only read the most recent comments, but I think I've got enough context to comment on the metadata arguments.

Based only on the fp-model command line options, the front end should only ever use "round.dynamic" (for strict mode) or "round.tonearest" (where full fenv access isn't permitted but we want to enable strict

In D62731#1619908, @lebedev.ri wrote:

In D62731#1619892, @mibintc wrote:

Compared to the 2nd revision, this patch moves all the changes into clang, removing the FPState file.

In the summary, I've copied information from Microsoft about the fp-model options into the differential Summary, as requested by Kevin, to create a legacy for future maintainers in case that information disappears from msdn.

The the documentation should be documentation, it should reside somewhere in clang/docs/.

Got it thanks

In D62731#1603030, @kpn wrote:

I actually don't have much of an opinion on what the command line argument form should be. It may be helpful for it to be the same as one of the commonly deployed compilers. The worst I think would be pretty close but with subtle differences. So if it can be made to work like Intel's compiler I'm fine with that. But I'm hoping that more people in the community chime in since having a consensus would be best. Personally, I'm not yet giving any final sign-offs to tickets since I don't think I've been here long enough.

As far as the rounding metadata argument, the language reference says this:

For values other than “round.dynamic” optimization passes may assume that the actual runtime rounding mode (as defined in a target-specific manner) matches the specified rounding mode, but this is not guaranteed. Using a specific non-dynamic rounding mode which does not match the actual rounding mode at runtime results in undefined behavior.

Be aware that currently neither of the metadata arguments does anything. They get dropped when llvm reaches the SelectionDAG. And none of the optimization passes that run before that know anything about constrained intrinsics at all. This means they treat code that has them conservatively. Preserving and using that metadata in the optimization passes and getting it down and used by the MI layer is planned but hasn't happened yet. So the full set of arguments may not make sense yet, but an on/off switch for strict mode hopefully does.

In D62731#1601408, @kpn wrote:

In D62731#1601310, @mibintc wrote:

I think it would be convenient to have an "unset" setting for the different constrained modes, otherwise you need a boolean that says "no value was provided for this option". But i'm a frontend person so I may need to have my attitude adjusted.

What "different constrained modes"? The IRBuilder is either in constrained mode or it isn't. In constrained mode the exception behavior and rounding mode both have defaults, and those defaults can be changed individually without affecting the other setting. The current defaults can also be retrieved if you need something for a function call where you don't want to change it but need an argument anyway. When do you need this "no value provided" setting?

Oh, I'd check the tools/clang/CODE_OWNERS.txt file and add additional appropriate reviewers. Perhaps John McCall and Richard Smith? I don't know who has opinions on how command line options should be handled.

Do we want the Unix driver to be compatible with gcc? Maybe, maybe not. Opinions, anyone?

Yes we need opinions on this.

The documentation request from lebedev.ri isn't in this ticket yet.

I'm not yet sure what I need for this, the requested documentation is still missing.

Also, for future historical research purposes I'd cut and paste the relevant portions of outside web pages (like intel.com's) and post them somewhere llvm-ish where they are findable. This ticket, for example, is a good place. Web sites gets reorganized or vanish in full or in part. It's helpful to have some insulation from that over time. I've had to fix compiler bugs that actually were 25 years old before. Yes, 25 years old. Being able to do the research is very helpful.

Oh, it may be useful to know that constrained floating point and the FastMathFlags are not mutually exclusive. I don't know if that matters here or not, but you did mention FastMathFlags.

Yes they aren't mutually exclusive. One of the fp-model options implies enabling fast math.

Compared to the 2nd revision, this patch moves all the changes into clang, removing the FPState file.

Thanks for your review >>! In D62731#1601408, @kpn wrote:

In D62731#1601310, @mibintc wrote:

I think it would be convenient to have an "unset" setting for the different constrained modes, otherwise you need a boolean that says "no value was provided for this option". But i'm a frontend person so I may need to have my attitude adjusted.

What "different constrained modes"? The IRBuilder is either in constrained mode or it isn't. In constrained mode the exception behavior and rounding mode both have defaults, and those defaults can be changed individually without affecting the other setting. The current defaults can also be retrieved if you need something for a function call where you don't want to change it but need an argument anyway. When do you need this "no value provided" setting?

I'm going to rewrite this

Oh, I'd check the tools/clang/CODE_OWNERS.txt file and add additional appropriate reviewers. Perhaps John McCall and Richard Smith? I don't know who has opinions on how command line options should be handled.

I'd like to fix it more before I add more reviewers

Do we want the Unix driver to be compatible with gcc? Maybe, maybe not. Opinions, anyone?

Oh, I think you mean something more like the gnuish -fno-except or maybe -fp-model=no-except? instead of -fp-model=except- ok we can get that sorted.

The documentation request from lebedev.ri isn't in this ticket yet.

Also, for future historical research purposes I'd cut and paste the relevant portions of outside web pages (like intel.com's) and post them somewhere llvm-ish where they are findable. This ticket, for example, is a good place. Web sites gets reorganized or vanish in full or in part. It's helpful to have some insulation from that over time. I've had to fix compiler bugs that actually were 25 years old before. Yes, 25 years old. Being able to do the research is very helpful.

That's a good idea thanks

Oh, it may be useful to know that constrained floating point and the FastMathFlags are not mutually exclusive. I don't know if that matters here or not, but you did mention FastMathFlags.

Yes i'm not sure how the fast math command line optoins should interact with the fp-model options, i'll have to dig into that.

The IRBuilder now has been taught about constrained fadd and friends. I simply updated my patches to work with the committed revision. Note that this diff now contains what was formerly being reviewed separately in clang+llvm. Also let's discuss the new llvm file fpState.h. In this revision I didn't spend a lot of time pondering the best way to support this in the current world, i just made a simple update so it would build.

This works for me, I redid my patches adding fp-model options to work with this newest changeset, (but I haven't yet uploaded them.)

I'm abandoning this patch in deference to @kpn 's patch under review D53157

In D53157#1525311, @kpn wrote:

Oh, this ticket is not going to die from neglect. It is true that D43515 is a higher priority, but I need this IRBuilder work done as well. My department head wanted it done by the end of _last_ year. It's not going to die.

How about I merge your changes into this ticket and we continue work over here? There is the issue of the documentation that lebedev.ri asked you to write. Can I talk you into putting that together and sending it to me <kevin.neal@sas.com>? I'll work on the documentation that I was asked to write. Between the two of us we should be in pretty good shape. Does that work for you?

Yes I'll do that. Thanks.

I am still waiting for feedback from an actual consumer of the IRBuilder who will be using this new functionality. If someone clang-side could chime in on this ticket I'd very much appreciate it.

I wrote a clang patch that works with your IRBuilder modifications. I also checked with the Intel fortran team and they think this interface will be workable for them too. From Intel perspective it's +1.

I've posted a small change to this patch here, https://reviews.llvm.org/D62730 and there's a patch to add clang fp options here, https://reviews.llvm.org/D62731

I'll modify this to be a cc1 only option, there doesn't seem to be community interest.

@rjmccall Can you take a look at this patch or recommend someone who can review it? Many thanks. --Melanie

@dexonsmith Can you take a look at this patch or recommend someone who can review it? Many thanks. --Melanie

respond to suggestion from @xbolva00 (thanks). Added a test case where prefix fails to match

added an inline comment about the use of strncmp

The bug should be fixed at the atomic-load (drop _Atomic qualifier) then this patch won't be needed in StmtExpr

In D59307#1427853, @erichkeane wrote:

This is my concern here:
https://godbolt.org/z/icS4fa
The patch will change template instantiation.

GCC doesn't seem to allow using _Atomic in C++ mode, which is perhaps a necessary part of this solution? I see we already consider overload sets with int and _Atomic(int) to be ambiguous (in addition to not considering conversion operators of _Atomic(int) at all??), so it is limited to type deduction. I could see this causing problems, since specializations of templates are allowed on int and _Atomic(int) despite not being used in overload sets; https://godbolt.org/z/oMAvpz

In D59307#1428145, @jfb wrote:

In D59307#1428101, @mibintc wrote:

In D59307#1427644, @jfb wrote:

I think you also want to test C++ std::atomic ...

The bug described in https://bugs.llvm.org/show_bug.cgi?id=41033 doesn't occur using C++ atomic, I rewrote the test case this way, and it compiles without error. The "load" operation returns int since all the atomic operations occur under the covers using builtins. Does this convey the test you have in mind?

#include <atomic>
int fum(int y) {

std::atomic<int> x(1);
y = ({x.load();});

}

What I had in mind with atomic isn't relevant, because it would try to call atomic(const atomic&) = delete;. Your test case here isn't something I'm worried about.

volatile is still and issue.

I'm still not sure this is something we want.

In D59307#1427644, @jfb wrote:

I think you also want to test C++ std::atomic ...

In D59307#1427663, @jfb wrote:

Thinking some more, this is really a silly gotcha in code. We should probably follow what we're about to do with wg21.link/P1152 and ban chaining. Statement expressions should therefore not be allowed to return _Atomic, std::atomic, nor volatile.

In D59307#1427665, @jfb wrote:

From an offline discussion, I'm told that @jwakely uses this in GCC headers and expects some semantics from it? Jonathan, why?!?!

Thanks for test suggestions, will follow up

More info: gcc allows this with -fpermissive, Microsoft gives no message regardless of /permissive-

Hi @mibintc; would you mind confirming that ICC doesn't emit DWARF CC attributes or (if it does) that they don't overlap with the ones in this diff?

Sure i don't mind checking. While icc does support the calling conventions, the compiler is not emitting the dwarf calling convention attributes.

I added some inline comments. You are using the Intel 18.0 compiler on Windows - what version of Visual Studio is in the environment?

added inline replies to Eli and Hubert

I responded to comments from @eli.friedman and @hubert.reinterpretcast : I added FIXME comment regarding the "Q" suffix on the float 128 literals (gcc uses F128 but clang doesn't support this). Hubert pointed out that the floating point macros should only be enabled when float128 is enabled, so I added a check before defining them. I fixed a couple problems that Hubert pointed out in the test case.

I changed the patch to enable _Float128 only as keyword in mode "nocxx" - this is the same mode being used by _Bool. I changed the test from .cpp to .c; I run check-all and saw only the usual suspects fail. What do you think?

Thanks for all your reviews

I also posted this question on IRC

Updated the test diff to correspond to the D34158 patch uploaded today.

The patch to clang is the same as before. The modifications are to the test cases, I verified that all these test cases need modifications. I will also be updating the associated diff for clang/tools/extra, please review that as well. Without the test patches, these are the tests that fail (using check-all) . The failure mode is as described in a note I posted earlier this week, please let me know if you need further details. @jyknight Looking for your review and approval, thanks!

In D34158#905637, @mibintc wrote:

In D34158#905596, @jyknight wrote:

I'd still _very_ much like a solution that is acceptable for all libc to use, and have that on by default.

However, I guess this is fine.

Only concern I have is that it seems odd that so many test-cases needed to be changed. What fails without those test changes?

Those tests fail because they generate preprocessed output and then check carefully for precise results. Since the preprocessed output is different, the comparison fails. I "fixed" the tests by adding the freestanding option which inhibits the new behavior. I'll have to check out and rebuild everything so I can show you exactly the failure mode, I expect I can post details tomorrow.

In D34158#905596, @jyknight wrote:

I'd still _very_ much like a solution that is acceptable for all libc to use, and have that on by default.

However, I guess this is fine.

Only concern I have is that it seems odd that so many test-cases needed to be changed. What fails without those test changes?

Hey @jyknight I heard from @erichkeane that you may want a couple more changes to this patch. Please let me know if you have some changes to recommend. @joerg thought this was OK for submission. Thanks --Melanie

Updating to latest version. No change other than that.

I heard that @jyknight is still interested in this functionality, updating the patch to latest sources, to do this i needed to make a small change to a couple of driver tests. Other than that it's the same as previous submission.

Another ping. Is it possible to approve this modification, or alternatively, let me know that it won't be approved indefinitely? I understand that it's a controversial change. Thanks!

ping

@jyknight recommended adding the new option to skipArgs in Job.cpp. This revision makes that change and tests that in crash-report.c; look OK?

Need TO FIX: We should be stripping the new arg as well: add "-fsystem-include-if-exists" argument to the list of include things in the skipArgs() function in lib/Driver/Job.cpp

This patch is responding to @jyknight 's concern about preprocessed input. The patch as it stands doesn't have this issue. I added 2 test cases, one using option -x cpp-output, and another for a source file suffixed with .i

Responding to @fedor.sergeev 's comment. This is an updated patch which pulls out the "isValid" check on GCCInstallation. Also I'm putting back the dummy sysroot tree which contains stdc-predef.h and adding a new test run to confirm that the new option fsystem-include-if-exists is actually working.

Updating this patch to latest revision of tools/extra

In the last review, it was deemed less controversial if I move these updates back into the gnu/Linux tool chain. This revision is responding to that feedback. I also simplified the test case. I tested on Linux with check-all and check-clang and found no unexpected failures.

I will prepare another patch responding to joerg's comment:

This patch responds to @fedor.sergeev 's feedback from earlier today. This is a change to the test case test/Driver/stdc-predef.c in the situation that the system does not supply a version of stdc-predef.h. Fedor had suggested an option like -H which traces the include files, but the file stdc-predef.h does not appear in the -H standard include tracing even if it is available on the host system. Instead for this case I preprocess the simple test file, with sysroot pointing to a filesystem missing the file stdc-predef.h, and verify with FileCheck that the string stdc-predef.h doesn't appear in the preprocessed output.

Here's an updated patch which is using angle brackets to do the include, so the search for stdc-predef.h is limited to system directories. Also my previous revision was missing the new test cases since i had gotten a new sandbox but forgot to "svn add". This patch is showing the new test cases.

@erichkeane contacted me offline and pointed out I'm twine-ing with " not <. i'm planning to change the option name from "finclude if exists" to "fsystem include if exists", then i'll quote with < not ". hope to get this updated patch into review later today. let me know if you think i'm off track. thanks for all your careful review. i knew there was something wrong with the include like Fedor pointed out but i couldn't see where i went wrong.

Here is an updated diff which is rebased to current trunk per @fedor.sergeev 's suggestion (thank you). make check-all and check-clang are working for me on Linux with no unexpected failures.

I'm going to rebase the patch to latest.

Ping.

OK folks, I was off the grid last week but I'm back now, and at my grindstone again.
I haven't received any comments since I updated the patch to remove the checks on "-nostdinc".
Look OK to commit?
Many thanks for all your reviews
--Melanie

This patch corresponds to these modifications to clang: https://reviews.llvm.org/D34158?id=105904

I removed the check on -nostdinc; and made some updates to the test cases

I need to redo the test changes. Will resubmit the diff.

In D34158#803752, @jyknight wrote:

This version is still disabling upon -nostdinc, which doesn't make sense to me.

You didn't remove that, nor respond explaining why you think it does make sense?

With the latest proposed fix for D34158, a few more test corrections are needed. The correction consists of suppressing the new preprocessor behavior. D34158 preincludes the file <stdc-predef.h> if the file is available.

I updated the patch as James directed, moving the preinclude of stdc-predef.h into clang.cpp and out of the Linux toolchain entirely. I also needed to update a couple more tests in tools/extra, so I will need to update that related differential as well.

I rewrote the patch the way that Richard suggested, adding a cc1 option "finclude-if-exists" and injecting #if __has_include etc. [OK to use finclude? include-if-exists preferred?]
I responded to James' remarks and removed the gcc version check.
Does this look better?

Jonas asked about adding a new test to ensure that "-include stdc-predef.h" does not get added if the file doesn't exist.

I responded to the review from Jonas Hahnfeld: I moved the entire change into ToolChains/Linux and removed the modifications to Gnu.h and Gnu.cpp; I modified the new tests to use -### with FileCheck, and added a tree in Inputs/ for the new tests. Jonas please see inline reply concerning whether to--or how to--check for existence of stdc-predef.h

In D34158#797968, @Hahnfeld wrote:

In D34158#797170, @mibintc wrote:

The other test that fails is my own new test! It fails because I don't know how to set it up so the test thinks it has a gcc toolchain with version > 4.8. I tried using gcc-toolchain set to various other Linux toolchains that i see in the test/Driver/Inputs - none of them cause the gcc version to be in the range. I also tried using -ccc-installation=Inputs/ which I see being used for gcc version parsing. How can I set up the test so that the GCCInstallation has a Version >= 4.8? I test the new functionality from the console on Linux and can confirm it's working.

You could try adding a completely new directory in Inputs/. Add the directory usr/lib/gcc/x86_64-unknown-linux/4.9.0 underneath which should be recognized as the version. Maybe you have to add some more files, I'm not really familiar with the detection mechanism...