Page MenuHomePhabricator
Feed Advanced Search

Mon, Jan 14

kristina committed rL351082: [Sema] Expose a control flag for integer to pointer ext warning.
[Sema] Expose a control flag for integer to pointer ext warning
Mon, Jan 14, 10:21 AM
kristina committed rC351082: [Sema] Expose a control flag for integer to pointer ext warning.
[Sema] Expose a control flag for integer to pointer ext warning
Mon, Jan 14, 10:20 AM
kristina closed D56241: [Sema] expose a control flag for integer to pointer ext warning.
Mon, Jan 14, 10:20 AM · Restricted Project
kristina added a comment to D56241: [Sema] expose a control flag for integer to pointer ext warning.

Going to test and land it as requested by @lebedev.ri on IRC.

Mon, Jan 14, 9:26 AM · Restricted Project

Sun, Jan 13

kristina added a comment to D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..

Currently actual tests would require using libgcc, as compiler-rt does not support split stack yet. If libgcc is required for tests then I don't think I can accurately make one. So if you require a test for this, it's likely that I'll have to mark this as "Changes Planned" for now until compiler-rt is sufficient to link this, unfortunately. Up to you really, though in my opinion even without tests this is better than it failing to compile. And the reasons for avoiding libgcc are fairly complicated, my intentions currently are to stay as far away from GNU runtime components as possible.

Sun, Jan 13, 2:40 PM
kristina added a comment to D28791: [compiler-rt][crt] Simple crtbegin and crtend implementation.

FWIW, I completely support landing this. I think the opposition is essentially "it would be better to not design a libc in that way" which is certainly a valid opinion, but given the existence of such libc designs widely deployed and widely used, it seems very good to lay groundwork for LLVM to support them.

I also think we should *not* be pointing at GNU or any other project here, and instead simply state that these exist to support using LLVM in conjunction with systems whose libc chooses this particular design pattern.

I don't think LLVM should be in the business of trying to cast some kind of "you should feel bad" judgement on such systems. If someone in the LLVM community wants to develop a libc as part of LLVM (which I would quite like to see), then that is the place to debate libc design decisions, and not anywhere else.

So, that said, does anyone have comments on the code itself? If no one is up to commenting on the code and giving Petr direct feedback there, I'll just LGTM this because I think it is long (looooooong) overdue.

Lastly, to address specific questions here:

That's fine, it's just not the state of the world and we should support compiling appropriately.

I don't want to pick a fight, but there can be used exactly same argument to defend pulling libgcc here.

That doesn't make sense to me -- the LLVM project has lots of reasons why it doesn't pull GPL-ed code into its tree.

But yes, we are going to be in the business of being 100% and fully compatible with libgcc in order to effectively support platforms based on libcs that follow the design pattern of glibc, certainly including platforms that use glibc. Is that work? Yes. Should the project do it? Absolutely yes. Just like we work hard to be compatible with the gcc commandline and other layers of compatibility, we should work to support these platforms well.

Sun, Jan 13, 1:34 AM

Sat, Jan 12

kristina added a comment to D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..

Changes to runtime.go address the regression caused by rL322965.

Sat, Jan 12, 8:22 AM
kristina created D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..
Sat, Jan 12, 8:18 AM

Thu, Jan 10

kristina added a comment to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

Addressed all comments, will wait for feedback and then do the final draft, and if people are happy with that, I'll lint the whole file and then commit it.

Thu, Jan 10, 2:41 AM

Wed, Jan 9

kristina added a comment to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

! In D56482#1350874, @kristina wrote:

I only added a section, all the warnings are from existing bits below. Not sure if it's a good idea to reformat it as part of the diff as it will make it harder to see the added section. Can do it afterwards but that's what's currently being used to generate documentation.

Sorry I wasn't clear, I'm using a script from D55523: [clang-tidy] Linting .rst documentation to validate .rst files, if you read the revision there is some info on the rational. (I simply ran it here on a copy of the file you are editing prior to your revision). You'll see from D55523 that I mention that I saw a lot of review comments which amounted to stylistic changes in the .rst files, and yet I see a lot of reviewers time pointing these out, time and time again and its all simple stuff that could be automated. (or at least added to such a how to guide)

it would be good if we could ensure .rst files are checked prior to review (how we do this I don't know) without initially generating 10,000 of minor whitespaces changes.

when I reviewed all .rst files currently checked into LLVM I found 10,000's of simple violations (maybe people aren't worried about it but certainly it comes up a lot in reviews and causes the second or third revisions)

I think another point is that lot of review comments could potentially be caught by clang-tidy, there is sometimes lots of the review conversations especially with new contributors, about "don't use anonymous namspaces but prefer static functions","clang-format the file", don't overly use auto", don't have "const value types" all stuff that is in the CodingStyle but is easily missed when making or updating a review.

It would be good if we had a mechanism to be able to validate a patch prior to commit, maybe using something like clang-tidy-diff.py in combination with something like the .rst linter to reduce the iterations on a revision, speed up development and reduce the burden that seems present on a group of dedicated but possible select people.

Wed, Jan 9, 12:52 PM
kristina added a comment to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

$ ./validate_check.py --rst ../../../../../docs/Phabricator.rst
Checking ..\..\..\..\..\docs\Phabricator.rst...
warning: line 97 multiple blank lines
warning: line 166 is in excess of 80 characters (82) : as it will retrieve reviewers, the `Differential Revision`, etc from the review
...
warning: line 175 contains double spaces
warning: line 188 is in excess of 80 characters (97) : The first command will take the latest version of the reviewed patch and apply it to the working
...
warning: line 194 is in excess of 80 characters (111) : This presumes that the git repository has been configured as described in :ref:developers-work-with-git-svn.
...
warning: line 203 multiple blank lines
warning: line 205 is in excess of 80 characters (84) : current `master and will create a commit corresponding to D<Revision>` with a
...
warning: line 208 is in excess of 80 characters (85) : Check you are happy with the commit message and amend it if necessary. Now switch to
...
warning: line 218 multiple blank lines
warning: line 219 multiple blank lines

Wed, Jan 9, 2:45 AM
kristina added a reviewer for D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator.: lebedev.ri.
Wed, Jan 9, 1:59 AM
kristina added inline comments to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..
Wed, Jan 9, 1:59 AM
kristina updated the diff for D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

Spellcheck.

Wed, Jan 9, 1:54 AM
kristina created D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..
Wed, Jan 9, 1:45 AM

Tue, Jan 8

kristina updated subscribers of rL350671: [PGO] Use SourceFileName rather module name in PGOFuncName.

+llvm-commits

Tue, Jan 8, 5:25 PM
kristina raised a concern with rL350671: [PGO] Use SourceFileName rather module name in PGOFuncName.

Unaddressed issues in pre-commit review.

Tue, Jan 8, 5:05 PM
kristina added a comment to D55769: Add support for demangling msvc's noexcept types to llvm-undname.

lgtm. I'm technically on vacation so rnk@ might be able to commit it sooner than I can, but if he doesn't, then I'll commit it when I find some spare cycles. Thanks for fixing this!

Hi @zturner, can you please commit this when you have a chance?

Tue, Jan 8, 11:40 AM
kristina added a comment to D56327: [PGO] Use SourceFileName rather module name in PGOFuncName.

Differential Review is mostly for pre-commit review, add in "Differential Revision: https://reviews.llvm.org/DXXXXX" to the commit message and it will automatically link the commit and diff and close it. As an alternative you can do that manually, It seems bigger patch has already been committed in rL350579 (without review) and this was pending review rL350442. I've linked those in but if you say it's been fixed in the committed version and this is a followup, can you rebase the patch on the current trunk? For post-commit reviews Audit may be a better place if you need that.

Tue, Jan 8, 11:07 AM
kristina added 1 commit(s) for D56327: [PGO] Use SourceFileName rather module name in PGOFuncName: rL350442: [PGO] Use SourceFileName rather module name in PGOFuncName.
Tue, Jan 8, 11:03 AM
kristina added an edge to rL350442: [PGO] Use SourceFileName rather module name in PGOFuncName: D56327: [PGO] Use SourceFileName rather module name in PGOFuncName.
Tue, Jan 8, 11:03 AM
kristina added an edge to rL350579: [PGO] Use SourceFileName rather module name in PGOFuncName: D56327: [PGO] Use SourceFileName rather module name in PGOFuncName.
Tue, Jan 8, 10:57 AM
kristina added 1 commit(s) for D56327: [PGO] Use SourceFileName rather module name in PGOFuncName: rL350579: [PGO] Use SourceFileName rather module name in PGOFuncName.
Tue, Jan 8, 10:57 AM

Mon, Jan 7

kristina added a comment to D56383: [XRay][tools] Use symbols instead of function id.

Quite a big style nit. I'd say get rid of the switch completely.

Mon, Jan 7, 9:41 PM
kristina added a comment to D17741: adds __FILE_BASENAME__ builtin macro.

Ping for author? This is one of the changes I'd like to see through, though the complexity here can be massively reduced as stated above. I wouldn't mind opening a new diff if the author is away with just a change in PPMacroExpansion and a testcase (which should probably be included here) but I would appreciate some form of consensus since this exact idea with a special macro for filename was previously rejected.

Mon, Jan 7, 9:29 PM
kristina added a reviewer for D56383: [XRay][tools] Use symbols instead of function id: kristina.

Added some inline comments.

Mon, Jan 7, 9:09 PM
kristina requested changes to D56327: [PGO] Use SourceFileName rather module name in PGOFuncName.

I feel like this needs a test or amending an existing test, a bit too tired right now to patch this into my fork and run the test suite, but I feel as-is, this could cause test failures (and if it doesn't, that's likely indicative of missing coverage). Please address that before committing it. Also, see inline comments, first one is a style nit but I'm more concerned about uint32_t StripLevel = StaticFuncFullModulePrefix ? 0 : -1;.

Mon, Jan 7, 8:53 PM
kristina added a comment to D47073: Document and Enforce new Host Compiler Policy.

I could see it making bootstrapping LLVM a lot harder (plus "golden" versions of compilers tend to be older than three years). I like the spirit of this policy, but the timeframe is pretty narrow, does GCC currently have a "golden" version? I think we should at least make sure "golden" compilers are supported for bootstrap.

Mon, Jan 7, 7:18 PM
kristina added a reviewer for D56415: NFC: Port QueryParser to StringRef: kristina.

LGTM aside from one comment.

Mon, Jan 7, 6:05 PM
kristina added a comment to D56419: [gn build] Move .gn file to the root of the monorepo.

I'm neutral on the issue but I would urge Nico to really think this through, lashback from some major downstream Linux distro vendors last time was pretty nasty, including flat out dropping Clang/LLVM support if CMake became a second class citizen. Is rehashing the same thing again worth it? Consider that a lot of people, no matter what you say will see it as GN slowly creeping in to replace CMake, not many are familiar with it outside Google or Chromium/Skia contributors.

I'd like to reiterate that this patch does not change anything about LLVM's build system situation. CMake is the supported build system. GN is 100% unsupported (as I've added as a comment to the file as I moved it over). I do not intend to push for changing this.

Mon, Jan 7, 5:46 PM
kristina added a comment to D56419: [gn build] Move .gn file to the root of the monorepo.

I'm neutral on the issue but I would urge Nico to really think this through, lashback from some major downstream Linux distro vendors last time was pretty nasty, including flat out dropping Clang/LLVM support if CMake became a second class citizen. Is rehashing the same thing again worth it? Consider that a lot of people, no matter what you say will see it as GN slowly creeping in to replace CMake, not many are familiar with it outside Google or Chromium/Skia contributors.

Mon, Jan 7, 5:01 PM

Thu, Jan 3

kristina added a comment to D17741: adds __FILE_BASENAME__ builtin macro.

I should add that this is not just about reproducible builds but about code size as mentioned by @NSProgrammer. There are ways to cheat with builtins but the problem is, entire FILE string is still emitted into read-only data, despite the constexpressiveness of the value. The common way of getting the short filename in code would the the following (the #else case) which is a constant evaluated but has a side effect of dumping the full paths in rodata regardless (ICF seems unable to clean them up even in full LTO builds).

Thu, Jan 3, 11:17 AM
kristina committed rL350342: [MCStreamer] Use report_fatal_error in EmitRawTextImpl.
[MCStreamer] Use report_fatal_error in EmitRawTextImpl
Thu, Jan 3, 10:46 AM
kristina closed D56245: Use llvm_unreachable instead of errs+abort in MCStreamer.cpp (in EmitRawTextImpl). NFC..
Thu, Jan 3, 10:46 AM
kristina updated the diff for D56245: Use llvm_unreachable instead of errs+abort in MCStreamer.cpp (in EmitRawTextImpl). NFC..

Revised to be a fatal error after discussion and added comment for any future maintainers. Also made empty braced blocks consistent.

Thu, Jan 3, 10:40 AM
kristina added a comment to D17741: adds __FILE_BASENAME__ builtin macro.

To throw in my 2 cents. I don’t really have a preference between a compiler flag vs a different macro that’s just for the file name sans path prefix. But I have a real need for this to get into clang: with 1.2 million lines of code, the regular placement of log statements and custom asserts leads to megabytes in binary size from all the FILE usages, and that could easily be a few hundred KB with this kind of support in clang.

Thu, Jan 3, 8:04 AM
kristina added a reviewer for D56245: Use llvm_unreachable instead of errs+abort in MCStreamer.cpp (in EmitRawTextImpl). NFC.: rnk.
Thu, Jan 3, 6:58 AM
kristina added a comment to D17741: adds __FILE_BASENAME__ builtin macro.

I like the idea of just getting the filename reliably, but I think an extension to strip path prefixes is a bit of an overkill especially as yet another compiler flag. I implemented a similar thing in my fork in form of a directive to __generate(...) which is my own weird extension to do meta-programming using the preprocessor, that's the implementation with no extra parameters (just as an idea, I know the implementation is not great):

Thu, Jan 3, 6:53 AM

Wed, Jan 2

kristina added a comment to D56206: Introduce `RemoteAddressSpaceView` and `VMReadContext`..

Would it make sense to also extend this to Linux using process_vm_readv/process_vm_writev?

Wed, Jan 2, 11:14 PM
kristina created D56245: Use llvm_unreachable instead of errs+abort in MCStreamer.cpp (in EmitRawTextImpl). NFC..
Wed, Jan 2, 10:34 PM
kristina committed rL350286: Don't go over 80 chars in MCStreamer.cpp. NFC..
Don't go over 80 chars in MCStreamer.cpp. NFC.
Wed, Jan 2, 10:10 PM

Sun, Dec 30

kristina added a comment to D55953: Android is not GNU, so don't claim that it is..

Seems good, it could eliminate the need for a lot of preprocessor checks like #if __gnu_linux__ && !defined(__ANDROID__). It doesn't seem that there are any preprocessor checks where this would cause problems (from a quick search) since all of them seem to focus on making sure __gnu_linux__ being defined explicitly excludes Android from those paths.

Sun, Dec 30, 3:07 AM

Dec 15 2018

kristina added a comment to D54277: Move RedirectingFileSystem interface into header..

I'm not sure if this is way out of scope for this patch, but if I understand correctly this could be used for extending it to, for example, handle things like Perforce-style paths which could indeed be useful, although I'm not sure if that is possible (ie. would //depot/asdf behave differently on Windows and Linux/Darwin/any other OS that uses Unix-style paths?). If this is with the intention to allow extending RedirectingFileSystem downstream then I think it may be worth splitting it up from the YAML based implementation altogether, allowing custom path handling where needed (as a separate downstream extension), with the concrete reference implementation of RedirectingFileSystem (the YAML based one) being a separate thing. This would make it more extensible from the POV of downstream forks that may desire to implement path redirection that is too complicated to do using YAML mappings, but still fundamentally rely on some sort of path remapping.

Dec 15 2018, 1:11 PM
kristina added a comment to D55734: [analyzer] Revise GenericTaintChecker's internal representation.

If you don't mind, please submit diffs with full context (diff -U99999 or something alike depending on what you use). It makes it much easier to review patches. Also the formatting looks really off in some places where 4 spaces are used. Also another nitpick, nested statement ifs should have the statements within them aligned without adding another indentation level for every line break within the statement, also in case below dyn_cast_or_null may eliminate a need for an additional check in which case you can just use && instead.

Dec 15 2018, 2:23 AM
kristina added a comment to D54864: Introduce llvm-objdump man page.

Ping for author, this has been approved for a while, do you need this committed?

Dec 15 2018, 1:52 AM

Dec 6 2018

kristina accepted D54864: Introduce llvm-objdump man page.

LGTM.

Dec 6 2018, 1:24 PM
kristina requested changes to D55150: Emit warnings from the driver for use of -mllvm or -Xclang options..

I'm not sure that putting a warning that can be disabled really helps here; anyone who needs the option will just disable the warning anyway, and then users adding additional options somewhere else in the build system will miss the warning.

Instead, it would probably be better to rename Xclang and mllvm to something that makes it clear the user is doing something unsupported. Maybe "--unstable-llvm-option" and "--unstable-clang-option" or something like that. (This will lead to some breakage, but the breakage is roughly equivalent for anyone using -Werror.)

Dec 6 2018, 11:57 AM
kristina added a comment to D55150: Emit warnings from the driver for use of -mllvm or -Xclang options..

I don't have an opinion on this patch (if you force me to have one, I'm weakly in favor), but I agree with the general sentiment. When I told people to not use mllvm and Xclang before, they told me "but if I'm not supposed to use them, why are they advertised in --help"?

thakis@thakis:~/src/llvm-build$ bin/clang --help | grep Xclang
  -Xclang <arg>           Pass <arg> to the clang compiler
thakis@thakis:~/src/llvm-build$ bin/clang --help | grep mllvm
  -mllvm <value>          Additional arguments to forward to LLVM's option processing

Which to me is a valid point! Maybe we should remove them from --help or say "internal only, don't usually use" there?

Dec 6 2018, 11:12 AM
kristina added a comment to D55150: Emit warnings from the driver for use of -mllvm or -Xclang options..

There is a cost to having people encode these flags into their build systems -- it can then cause issues if we ever change these internal flags. I do not think any Clang maintainer intends to support these as stable APIs, unlike most of the driver command-line. But, neither -Xclang nor -mllvm obviously scream out "don't use this!", and so people may then add them to their buildsystems without causing reviewers to say "Wait...really? Are you sure that's a good idea?".

Dec 6 2018, 10:35 AM
kristina resigned from D50858: [M680x0] Add ELF and Triple info.
Dec 6 2018, 12:51 AM
kristina added a comment to D55150: Emit warnings from the driver for use of -mllvm or -Xclang options..

Personally I'm against this type of warning as it's likely anyone using -mllvm is actually intending to adjust certain behaviors across one or more passes with a lot of switches supported by it being intentionally hidden from <llvm_tool> --help output requiring explicitly specifying that hidden flags be shown. One real use case being a dozen of patches to my downstream LLVM/Clang fork, for example *very* experimental support for SEH on Itanium ABI. I feel like this is going to affect developers more than users as now additional flags will have to be passed to suppress the warnings generated from using flags to debug/diagnose passes by code authors themselves. I feel like using -mllvm already implies explicit understanding of that, and of the cl::opt semantics/purpose as well as the flags being generally out of public view unless one gets them from full help (which explicitly shows all registered flags, hidden or not), or from source code which is most likely to be the developers themselves.

Dec 6 2018, 12:26 AM

Dec 5 2018

kristina committed rC348368: [Haiku] Support __float128 for x86 and x86_64.
[Haiku] Support __float128 for x86 and x86_64
Dec 5 2018, 7:08 AM
kristina committed rL348368: [Haiku] Support __float128 for x86 and x86_64.
[Haiku] Support __float128 for x86 and x86_64
Dec 5 2018, 7:08 AM
kristina closed D54901: [Haiku] Support __float128 for Haiku x86 and x86_64.
Dec 5 2018, 7:08 AM · Restricted Project

Nov 30 2018

kristina added a comment to D55045: Add a version of std::function that includes a few optimizations..

FWIW, I'm slightly in favor of using different headers. For example, I just realized that this change currently leaves a bunch of baggage symbols laying around that the new code won't use, it would be easier to see that kind of thing if the internals of each function were just in it's own file.

I'm strongly against it. The harder it is to see all the implementations of a given function f, the harder it is to know they exist and keep them in sync. In my experience spreading these things out leads to real bugs.

@ldionne wrote:

This is why I would like for us to plan on a solution that is more easily maintainable in the face of N implementations, not just 2 implementations (disregarding the C++03 implementations).

I would like that too. but that's not a blocking issue on this review.
I also don't agree that we'll see more std::function implementations in the future. We won't. We're not going to standardize additional features to std::function unless they're not ABI breaking. That is, if the standard does function it'll won't require another version of it.
Maybe you were thinking about things like std::unique_function?

Note that having the C++03 functions be in a separate file with no relation or interleaving with the C++11 implementation has caused plenty of bugs in the past where they diverge.

Nov 30 2018, 9:22 PM
kristina added a reviewer for D54277: Move RedirectingFileSystem interface into header.: kristina.
Nov 30 2018, 6:16 AM

Nov 29 2018

kristina updated subscribers of D55045: Add a version of std::function that includes a few optimizations..

Subject: Re: [PATCH] D55045: Add a version of std::function that includes a few optimizations.
From: Jordan Soyke <jsoyke@google.com>

Do we need an additional config option for this?

On Thu, Nov 29, 2018 at 07:56 Kristina Brooks via Phabricator <reviews@reviews.llvm.org> wrote:

kristina added reviewers: ldionne, EricWF, kristina, phosek.
kristina added a comment.

Added reviewers. This will be a break in ABIv2 and Unstable ABI (since
they're the same at the moment), only Fuchsia uses it at the moment, as far
as I'm aware.

Nov 29 2018, 6:16 AM
kristina added reviewers for D55045: Add a version of std::function that includes a few optimizations.: ldionne, EricWF, kristina, phosek.

Added reviewers. This will be a break in ABIv2 and Unstable ABI (since they're the same at the moment), only Fuchsia uses it at the moment, as far as I'm aware.

Nov 29 2018, 4:56 AM

Nov 28 2018

kristina committed rC347833: Add Hurd target to Clang driver (2/2).
Add Hurd target to Clang driver (2/2)
Nov 28 2018, 7:52 PM
kristina committed rL347833: Add Hurd target to Clang driver (2/2).
Add Hurd target to Clang driver (2/2)
Nov 28 2018, 7:52 PM
kristina closed D54379: Add Hurd toolchain support to Clang.
Nov 28 2018, 7:52 PM
kristina committed rL347832: Add Hurd target to LLVMSupport (1/2).
Add Hurd target to LLVMSupport (1/2)
Nov 28 2018, 7:26 PM
kristina closed D54378: Add Hurd triplet to LLVMSupport.
Nov 28 2018, 7:25 PM
kristina accepted D54379: Add Hurd toolchain support to Clang.

Yes everything passes now, my bad for not noticing.

Nov 28 2018, 7:09 PM
kristina accepted D54379: Add Hurd toolchain support to Clang.

Actually nevermind, I'll just create them myself, seems like a strange bug.

Nov 28 2018, 7:08 PM
kristina added a comment to D54379: Add Hurd toolchain support to Clang.

Hm, yes you're right, the files aren't in the diff that Phab gives me, this is annoying. I wonder if it's stripping them from the diff for some reason, can you upload the raw diff?

Nov 28 2018, 6:48 PM
kristina added a comment to D54379: Add Hurd toolchain support to Clang.

Your tests don't pass:

Nov 28 2018, 3:49 PM
kristina added a comment to D54901: [Haiku] Support __float128 for Haiku x86 and x86_64.

Let me know if you need this committed.

Nov 28 2018, 4:55 AM · Restricted Project
kristina accepted D54901: [Haiku] Support __float128 for Haiku x86 and x86_64.

LGTM. (Revision of D53696)

Nov 28 2018, 4:46 AM · Restricted Project
kristina commandeered D53696: [Haiku] Support __float128 for Haiku x86 and x86_64.

New revision in D54901.

Nov 28 2018, 4:45 AM · Restricted Project
kristina abandoned D53696: [Haiku] Support __float128 for Haiku x86 and x86_64.
Nov 28 2018, 4:45 AM · Restricted Project

Nov 27 2018

kristina added a comment to D54379: Add Hurd toolchain support to Clang.

Alright, will patch it into my fork in a bit and try it out, if everything looks good, I'll land the stack. (Again huge sorry about this taking some time, have lots on my hands at the moment)

Nov 27 2018, 1:50 PM

Nov 25 2018

kristina added a comment to D54826: [Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms.

With regards to UNIX-style access/modification times, the options are to find a uniform duration for all file-systems that is clamped to the one with lowest precision (like 1us), or just settle for this as-is. Though having this documented would be good, going on a hunt to determine the quirks of each possible file-system may be pretty difficult, especially considering some may allow tuning of those values.

Nov 25 2018, 12:58 PM
kristina added a comment to D54826: [Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms.

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

I can't speak for the Windows side of things but what you are pointing out is a general question about applications taking into account that file properties may differ across platforms. This is orthogonal to file_status itself reporting file properties accurately.

It is and it isn't. This is a cross-platform API and users may expect the values to be somewhat similarly reported across platforms, especially given that there is no documentation on getLastAccessedTime() or getLastModificationTime().

If current file_status has 1 hour resolution on NTFS for access time, this patch is not going to make it any better or worse, nor affect behavior of applications that are querying files from NTFS.

Agreed, and I wasn't suggesting that it would. I was more wondering whether you had thoughts on people using this across platforms where they will get very different behavior from the same API. Personally, I think it's reasonable to report the values with whatever precision we have available to us. I think that should be documented on the public API part with a mention that the resolution is expected to differ depending on the file system and OS. WDYT?

Nov 25 2018, 12:42 PM
kristina added a comment to D54826: [Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms.

The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Revisions") so it's more clear why this was added

There have been enhancements to file_status that added more info without the requirement you stated (attach related revisions to this one), like:
https://reviews.llvm.org/D31110
https://reviews.llvm.org/D18456

This patch makes no changes to the existing API so there's no specific place that I can point to, but it improves accuracy of *every* site that calls getLastModification() and uses its value for comparisons, in and out-of-tree. It addresses 'false-negatives' (mistakenly considering that the mod time did not change because the change happened within 1 second) and 'false-positives' (when considering same mod time as 'changed' so as to be conservative against sub-second changes).

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

Nov 25 2018, 12:36 PM
kristina accepted D54826: [Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms.

I think your original patch is fine, with better explanation of the reasoning behind it. I would comment on the platform differences with regards to modification time precision, it will make it easier to understand the rationale whenever someone is reading/reviewing related code in the future.

Nov 25 2018, 12:19 PM
kristina added a comment to D54877: Update coding guidelines regarding use of `auto`.

LGTM, I think explicitly giving examples of when it's a good idea to use auto is helpful.

Nov 25 2018, 9:24 AM
kristina added a parent revision for D54378: Add Hurd triplet to LLVMSupport: D54379: Add Hurd toolchain support to Clang.
Nov 25 2018, 12:18 AM
kristina added a child revision for D54379: Add Hurd toolchain support to Clang: D54378: Add Hurd triplet to LLVMSupport.
Nov 25 2018, 12:18 AM
kristina removed a parent revision for D54379: Add Hurd toolchain support to Clang: D54378: Add Hurd triplet to LLVMSupport.
Nov 25 2018, 12:17 AM
kristina removed a child revision for D54378: Add Hurd triplet to LLVMSupport: D54379: Add Hurd toolchain support to Clang.
Nov 25 2018, 12:17 AM
kristina requested changes to D54826: [Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms.

Do we really need nanosecond precision with regards to this? The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Objects") so it's more clear why this was added. However, if there's no consumer for such API (pending review) there is no point in adding it. The main spirit of the library is to only provide what LLVM and related projects require, I don't think nanosecond precision support falls within that category (unless what I said earlier is the case, in which case please link it to this revision).

Nov 25 2018, 12:10 AM
kristina added a comment to D54758: [WebAssembly] Remove `using` statements from header files. NFC..

I think some redundant includes should definitely go (IWYU). Regarding more granular using declarations, honestly it's up to @ruiu, Clang and LLDB handle it by aliasing some of LLVM's common classes in their respective namespaces, maybe that could work for LLD too? In fact I'm guessing that's the purpose of lld/Common/LLVM.h, you could take a similar approach for Wasm specific stuff and limit the using statements to your namespace.

Nov 25 2018, 12:00 AM

Nov 24 2018

kristina added a comment to D54864: Introduce llvm-objdump man page.

Everything that is explicitly marked as non-hidden should be in the man-page.

Nov 24 2018, 11:45 PM
kristina added a comment to D53696: [Haiku] Support __float128 for Haiku x86 and x86_64.

Ping. Is the author still around? I'm happy to take over this revision if not, and add __FLOAT128__ but unless someone says _GLIBCXX_USE_FLOAT128 is actually defined by the toolchain, I'll remove that line, it looks like it really shouldn't be defined in the toolchain, but I don't have a Haiku toolchain around so I can't say for sure.

Nov 24 2018, 11:37 PM · Restricted Project

Nov 22 2018

kristina added a comment to D54379: Add Hurd toolchain support to Clang.

Ping. Would like someone else to co-review this, everything looks fine aside from tests (I think a portion of this could use a short unit test with regards to creating the actual target instance). Also your FileCheck test is only for invoking clang -cc1 from the looks, can you add coverage for static linker invocations (as driver is also generally used to invoke the linker, unless that's explicitly not the case on Hurd)?

Nov 22 2018, 3:40 PM
kristina requested changes to D53696: [Haiku] Support __float128 for Haiku x86 and x86_64.

Indeed. I agree the _GLIBCXX_USE_FLOAT128 is misplaced there. That comes from config.h in libstdc++. That's working around an issue in Haiku's build (libstdc++ is built by gcc, but then we try and use it with clang later)
I can remove that.

Is the FLOAT128 desireable?

Nov 22 2018, 3:29 PM · Restricted Project

Nov 21 2018

kristina added a comment to D53696: [Haiku] Support __float128 for Haiku x86 and x86_64.

Linux, Solaris and OpenBSD also define it where appropriate, it depends on the target. This is why it's much easier to review when full context (diff with -U 99999) is provided, and means that it has a much lower change of patch doing something unexpected.

Nov 21 2018, 5:38 PM · Restricted Project
kristina added a reviewer for D53696: [Haiku] Support __float128 for Haiku x86 and x86_64: kristina.

Do you mind resubmitting those with context? Also I would suggest asking Tom Stellard as he's in charge of handling cherrypicking patches to go into releases once the major rolls over and I think we're pretty close (?) to 7.0.1.

Nov 21 2018, 5:18 PM · Restricted Project

Nov 18 2018

kristina added a comment to D54379: Add Hurd toolchain support to Clang.

I'll re-review when I'm up, from a quick glance it looks much better but I'll have to patch it over my fork and try out a few things (Mostly x86_64 Linux and Darwin test suites). I think the test is lacking a bit, there's a lot of stuff that isn't covered, and there's a lack of negative tests (ie. when invalid input is supplied and matches the triple suffix). Feel free to run tests though, may find something before me, I'm a bit too tired to reconfigure my buildbot to do what I want right now, so I'll leave it until when I'm up. So yeah I may be being a bit nitpicky but I think tests could cover a little bit more.

Nov 18 2018, 12:55 AM

Nov 16 2018

kristina added a comment to D54379: Add Hurd toolchain support to Clang.

As discussed in #hurd, a few additional comments. The Hurd codepath should first check if the triple is eligible, ie. minimizing any cost to the driver invocation for most targets, which are not going to be Hurd. In fact I would wrap it in LLVM_UNLIKELY but that's just a suggestion. Once you confirmed that the triple in question is the one you're looking for (from the suffix), you can alter the existing triple. The std::string should be avoided here since even a zero length SmallVector will guarantee not allocating anything unless used. This may be worth factoring out into a separate function entirely, and another important point is avoiding any sort of unneeded overhead unless you've confirmed that it's the Hurd triple.

Nov 16 2018, 7:48 PM
kristina added a reviewer for D54379: Add Hurd toolchain support to Clang: rjmccall.
Nov 16 2018, 7:34 PM
kristina added a comment to D54379: Add Hurd toolchain support to Clang.

Also, this needs unit tests and FileCheck tests.

Nov 16 2018, 2:12 AM
kristina added inline comments to D54379: Add Hurd toolchain support to Clang.
Nov 16 2018, 2:00 AM
kristina added inline comments to D54379: Add Hurd toolchain support to Clang.
Nov 16 2018, 1:41 AM
kristina added a comment to D54379: Add Hurd toolchain support to Clang.

Commented on that particular idiom, there's two instances where it's used, aside from variable naming issues (pos should be Pos) it's very non idiomatic as far as rest of LLVM code goes, don't pass string literals around as const char*, prefer StringRef instead, that would also save you from needing to resort to using strlen later (sorry for previous comment, I didn't mean strcpy).

Nov 16 2018, 1:28 AM
kristina added a comment to D54379: Add Hurd toolchain support to Clang.

The other lost comment was regarding the functions where you're using strcpy instead of idiomatic LLVM and also creating unnecessary temporary std::string instances on the stack.

Nov 16 2018, 1:15 AM

Nov 15 2018

kristina abandoned D54605: [lld][ELF] Add negative test coverage for unknown "-z" flags..

Ah alright no problem, seems I didn't notice. Thanks for the quick review.

Nov 15 2018, 5:25 PM
kristina updated the diff for D54605: [lld][ELF] Add negative test coverage for unknown "-z" flags..

Revised to drop the change.

Nov 15 2018, 5:04 PM
kristina added a comment to D54605: [lld][ELF] Add negative test coverage for unknown "-z" flags..

Shall I fully abandon the revision or want me to leave the test for unknown flag failure in? (Unless one already exists and I missed it, additional coverage can't hurt regardless)

Nov 15 2018, 4:51 PM