Page MenuHomePhabricator
Feed Advanced Search

Yesterday

mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Thu, Aug 22, 1:00 PM · Restricted Project

Fri, Aug 16

mibintc updated the diff for D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Fri, Aug 16, 1:56 PM · Restricted Project
mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Fri, Aug 16, 1:32 PM · Restricted Project

Thu, Aug 15

mibintc added inline comments to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.
Thu, Aug 15, 1:07 PM · Restricted Project
mibintc added reviewers for D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior: rsmith, rjmccall.
Thu, Aug 15, 6:46 AM · Restricted Project

Wed, Aug 14

mibintc updated the diff for D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Wed, Aug 14, 1:27 PM · Restricted Project
mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Wed, Aug 14, 8:48 AM · Restricted Project

Fri, Aug 9

mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Fri, Aug 9, 8:36 AM · Restricted Project

Wed, Aug 7

mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Wed, Aug 7, 2:40 PM · Restricted Project
mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.
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.

Wed, Aug 7, 2:39 PM · Restricted Project
mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.
In D62731#1601408, @kpn 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.

Wed, Aug 7, 2:38 PM · Restricted Project
mibintc updated the diff for D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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

Wed, Aug 7, 2:32 PM · Restricted Project

Fri, Jul 26

mibintc added a comment to D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

Thanks for your review >>! In D62731#1601408, @kpn 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.

Fri, Jul 26, 12:05 PM · Restricted Project

Thu, Jul 25

mibintc abandoned D26636: patch for llvm/clang bug 25965, suppress warning diagnostic on float-to-bool conversion when in condition context.
Thu, Jul 25, 9:18 AM · Restricted Project
mibintc added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.
Thu, Jul 25, 9:13 AM · Restricted Project
mibintc updated the diff for D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.

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.

Thu, Jul 25, 9:11 AM · Restricted Project

Jun 24 2019

vladimirlaz <vladimir.lazarev@intel.com> committed rG4508874f8d12: [SYCL][clang-cc1] Add new cc1 option: -dependency-filter PREFIX to filter files… (authored by mibintc).
[SYCL][clang-cc1] Add new cc1 option: -dependency-filter PREFIX to filter files…
Jun 24 2019, 12:01 PM

Jun 17 2019

mibintc added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

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.)

Jun 17 2019, 7:10 AM · Restricted Project

Jun 3 2019

mibintc abandoned D62730: [RFC] Alternate implementation of D53157 IRBuilder for Constrained FP using enumeration vs MDNode and add support for fp-model and fp-speculation language options.

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

Jun 3 2019, 11:13 AM · Restricted Project

May 31 2019

mibintc added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.
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.

May 31 2019, 10:28 AM · Restricted Project
mibintc added inline comments to D62730: [RFC] Alternate implementation of D53157 IRBuilder for Constrained FP using enumeration vs MDNode and add support for fp-model and fp-speculation language options.
May 31 2019, 8:53 AM · Restricted Project
mibintc added inline comments to D53157: Teach the IRBuilder about constrained fadd and friends.
May 31 2019, 8:19 AM · Restricted Project
mibintc added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

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

May 31 2019, 7:23 AM · Restricted Project
mibintc created D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior.
May 31 2019, 7:03 AM · Restricted Project
mibintc updated the summary of D62730: [RFC] Alternate implementation of D53157 IRBuilder for Constrained FP using enumeration vs MDNode and add support for fp-model and fp-speculation language options.
May 31 2019, 7:03 AM · Restricted Project
mibintc created D62730: [RFC] Alternate implementation of D53157 IRBuilder for Constrained FP using enumeration vs MDNode and add support for fp-model and fp-speculation language options.
May 31 2019, 6:56 AM · Restricted Project

May 30 2019

vladimirlaz <vladimir.lazarev@intel.com> committed rG11c512cbedf2: [SYCL] Restriction : cannot capture class static var in kernel code (authored by mibintc).
[SYCL] Restriction : cannot capture class static var in kernel code
May 30 2019, 8:08 AM
Vladimir Lazarev <vladimir.lazarev@intel.com> committed rGed0ea4527a51: [SYCL] Captured enum variables are incorrect inside SYCL kernels for CPU device (authored by mibintc).
[SYCL] Captured enum variables are incorrect inside SYCL kernels for CPU device
May 30 2019, 8:05 AM
Vladimir Lazarev <vladimir.lazarev@intel.com> committed rG971fecdc3169: [SYCL] fix MarkFunction ASTConsumer issue with delayed instantiations (authored by mibintc).
[SYCL] fix MarkFunction ASTConsumer issue with delayed instantiations
May 30 2019, 8:04 AM
Vladimir Lazarev <vladimir.lazarev@intel.com> committed rGe878f1d0a806: [SYCL] Add option fsycl-allow-func-ptr which defaults to false (authored by mibintc).
[SYCL] Add option fsycl-allow-func-ptr which defaults to false
May 30 2019, 8:03 AM
vladimirlaz <vladimir.lazarev@intel.com> committed rG4efe9fcf2dc6: [SYCL] Language restrictions for SYCL kernel functions from 6.3 section (authored by mibintc).
[SYCL] Language restrictions for SYCL kernel functions from 6.3 section
May 30 2019, 8:01 AM
mibintc abandoned D61743: New clang option -MD-filter=prefix to filter files from make dependencies.

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

May 30 2019, 5:54 AM · Restricted Project, Restricted Project

May 20 2019

mibintc added a comment to D61743: New clang option -MD-filter=prefix to filter files from make dependencies.

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

May 20 2019, 6:39 AM · Restricted Project, Restricted Project
mibintc added a reviewer for D61743: New clang option -MD-filter=prefix to filter files from make dependencies: rjmccall.
May 20 2019, 6:39 AM · Restricted Project, Restricted Project

May 17 2019

mibintc added a reviewer for D61743: New clang option -MD-filter=prefix to filter files from make dependencies: dexonsmith.
May 17 2019, 6:28 AM · Restricted Project, Restricted Project
mibintc added a comment to D61743: New clang option -MD-filter=prefix to filter files from make dependencies.

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

May 17 2019, 6:28 AM · Restricted Project, Restricted Project

May 10 2019

mibintc updated the diff for D61743: New clang option -MD-filter=prefix to filter files from make dependencies.

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

May 10 2019, 2:15 PM · Restricted Project, Restricted Project

May 9 2019

mibintc added a comment to D61743: New clang option -MD-filter=prefix to filter files from make dependencies.

added an inline comment about the use of strncmp

May 9 2019, 1:59 PM · Restricted Project, Restricted Project
mibintc created D61743: New clang option -MD-filter=prefix to filter files from make dependencies.
May 9 2019, 10:02 AM · Restricted Project, Restricted Project

Mar 14 2019

mibintc abandoned D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.

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

Mar 14 2019, 9:08 AM · Restricted Project
mibintc added a comment to D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.

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

Mar 14 2019, 9:07 AM · Restricted Project
mibintc added a comment to D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.
In D59307#1428145, @jfb 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.

Mar 14 2019, 9:02 AM · Restricted Project

Mar 13 2019

mibintc added a comment to D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.
In D59307#1427644, @jfb wrote:

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

Mar 13 2019, 1:43 PM · Restricted Project
mibintc added a comment to D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.
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.

Mar 13 2019, 11:21 AM · Restricted Project
mibintc added a comment to D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.
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?!?!

Mar 13 2019, 11:21 AM · Restricted Project
mibintc added a comment to D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.

Thanks for test suggestions, will follow up

Mar 13 2019, 11:16 AM · Restricted Project
mibintc created D59307: Patch llvm bug 41033 concerning atomicity of statement expressions.
Mar 13 2019, 9:51 AM · Restricted Project

Feb 13 2019

Herald added a project to D55741: Implementation Feature Test Macros for P0722R3: Restricted Project.
Feb 13 2019, 11:40 AM · Restricted Project

Jan 9 2019

mibintc requested changes to D56473: Allow 'static' storage specifier on an out-of-line member function template declaration in MSVCCompat mode.

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

Jan 9 2019, 12:15 PM

Apr 17 2018

mibintc created D45738: Add Microsoft mangling for _Float16, similar to technique used for _Complex.
Apr 17 2018, 2:18 PM

Mar 21 2018

mibintc added inline comments to D44426: Fix llvm + clang build with Intel compiler .
Mar 21 2018, 8:37 AM
mibintc added a comment to D42350: Add constructor DWARF calling convention for every supported LLVM CC.

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.

Mar 21 2018, 7:58 AM

Mar 19 2018

mibintc added a comment to D44426: Fix llvm + clang build with Intel compiler .

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

Mar 19 2018, 12:15 PM

Dec 4 2017

mibintc added a comment to D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

added inline replies to Eli and Hubert

Dec 4 2017, 11:30 AM · Restricted Project
mibintc updated the diff for D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

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.

Dec 4 2017, 11:28 AM · Restricted Project

Dec 1 2017

mibintc updated the diff for D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

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?

Dec 1 2017, 1:21 PM · Restricted Project
mibintc reclaimed D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.
Dec 1 2017, 1:18 PM · Restricted Project
mibintc abandoned D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

Thanks for all your reviews

Dec 1 2017, 10:11 AM · Restricted Project

Nov 30 2017

mibintc added reviewers for D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26: erichkeane, cfe-commits.
Nov 30 2017, 1:30 PM · Restricted Project
mibintc created D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.
Nov 30 2017, 1:30 PM · Restricted Project

Nov 22 2017

mibintc reopened D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

I also posted this question on IRC

Nov 22 2017, 8:59 AM

Oct 27 2017

mibintc added reviewers for D34624: extra test modifications for D34158: erichkeane, jyknight.
Oct 27 2017, 6:19 AM · Restricted Project
mibintc updated the diff for D34624: extra test modifications for D34158.

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

Oct 27 2017, 6:18 AM · Restricted Project
mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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!

Oct 27 2017, 6:11 AM

Oct 25 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .
Oct 25 2017, 8:02 AM
mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Oct 25 2017, 7:36 AM

Oct 24 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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?

Oct 24 2017, 1:22 PM

Sep 19 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Sep 19 2017, 8:31 AM

Sep 12 2017

mibintc updated the diff for D34624: extra test modifications for D34158.

Updating to latest version. No change other than that.

Sep 12 2017, 1:06 PM · Restricted Project
mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Sep 12 2017, 6:35 AM

Sep 7 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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!

Sep 7 2017, 7:33 AM

Aug 17 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

ping

Aug 17 2017, 12:34 PM

Aug 14 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

@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?

Aug 14 2017, 10:06 AM

Aug 11 2017

mibintc planned changes to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Aug 11 2017, 6:48 AM

Aug 10 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Aug 10 2017, 1:17 PM

Aug 8 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Aug 8 2017, 7:30 AM

Aug 7 2017

mibintc updated the diff for D34624: extra test modifications for D34158.

Updating this patch to latest revision of tools/extra

Aug 7 2017, 12:55 PM · Restricted Project
mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Aug 7 2017, 12:54 PM

Aug 1 2017

mibintc retitled D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available from For standards compatibility, preinclude <stdc-predef.h> if the file is available to For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .
Aug 1 2017, 5:53 AM
mibintc planned changes to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Aug 1 2017, 5:52 AM

Jul 31 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Jul 31 2017, 2:19 PM

Jul 28 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Jul 28 2017, 10:12 AM
mibintc planned changes to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

@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.

Jul 28 2017, 8:44 AM

Jul 27 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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.

Jul 27 2017, 1:38 PM
mibintc planned changes to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

I'm going to rebase the patch to latest.

Jul 27 2017, 10:28 AM

Jul 26 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

Ping.

Jul 26 2017, 8:09 AM

Jul 18 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Jul 18 2017, 10:30 AM

Jul 10 2017

mibintc updated the diff for D34624: extra test modifications for D34158.

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

Jul 10 2017, 1:12 PM · Restricted Project
mibintc updated the summary of D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .
Jul 10 2017, 1:09 PM
mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Jul 10 2017, 1:08 PM
mibintc planned changes to D34624: extra test modifications for D34158.

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

Jul 10 2017, 12:42 PM · Restricted Project
mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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?

Jul 10 2017, 10:05 AM
mibintc updated the diff for D34624: extra test modifications for D34158.

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.

Jul 10 2017, 8:11 AM · Restricted Project
mibintc retitled D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available from to support gcc 4.8 (and newer) compatibility on Linux, preinclude <stdc-predef.h> to For standards compatibility, preinclude <stdc-predef.h> if the file is available .
Jul 10 2017, 8:00 AM

Jul 9 2017

mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <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.

Jul 9 2017, 6:13 AM

Jul 6 2017

mibintc updated the summary of D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .
Jul 6 2017, 1:55 PM
mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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?

Jul 6 2017, 1:55 PM

Jul 5 2017

mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Jul 5 2017, 2:08 PM
mibintc updated the diff for D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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

Jul 5 2017, 1:48 PM
mibintc added a comment to D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available .

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...

Jul 5 2017, 1:19 PM