User Details
- User Since
- Oct 23 2018, 12:36 AM (222 w, 5 d)
May 17 2022
yes, please, Samuel Thibault <samuel.thibault@ens-lyon.org> will be fine, thanks
May 16 2022
This is still not showing up on https://github.com/llvm/llvm-project/blob/main/llvm/lib/WindowsManifest/CMakeLists.txt , is there some more steps needed from my side?
Jan 11 2022
Apr 27 2021
I try to make Hurd.cpp close to Linux.cpp in general, yes.
No, for now it only supports i686.
This part is actually already being tested by hurd.cpp, /usr/include/i386-gnu wouldn't be getting included otherwise.
Rebase on refreshed D101331
Rebase on newer D101317
Fix triplet
Rather use i686-gnu triplet
@MaskRay could you review this one as well? Most others are based on it.
Retrigger buildable with the dep
Fix clang-tidy warning
Retrigger buildable
Retrigger buildable
FI, I don't have commit access.
Apr 26 2021
Move all tests to hurd.cpp
Fix GCCInstallation.isValid use in Generic_GCC::addLibStdCxxIncludePaths
Fix test further
Fix test
Aug 3 2020
Oh.
It was committed already as c298e5a022928b59941d74680a41fc9c76038b2a ("[Gnu toolchain] Move GCC multilib/multiarch paths support from Linux to Gnu") but apparently with the wrong Differential Revision (D73845 instead of D74282).
Now closing.
Apr 25 2020
Apr 24 2020
@MaskRay : Samuel Thibault <samuel.thibault@ens-lyon.org>
Apr 23 2020
Thanks! I don't have commit access, could somebody commit this for me?
Apr 22 2020
ping @phosek ?
Apr 9 2020
Feb 25 2020
Hello, any news on this?
Feb 8 2020
I however didn't find how to specify in phabricator a dependency between the two diffs, is that supported in phabricator?
I feel like in this specific case it may be worth splitting this into two patches:
Alright, doing so.
I feel like in this specific case it may be worth splitting this into two patches:
Right, here is an updated patch
Feb 2 2020
There is no behavior change, I checked for no regression on GNU/Linux with ninja check-all.
Jan 5 2020
Let me know if you need this committed.
I am actually getting many failures with ninja check-all on my build box:
(I don't see anything looking like what you have, so can't investigate)
Which checksuite are you running? I had been using ninja check-all, and I do indeed get unexpected failures, but exactly the same set of failures as when building against master.
Dec 30 2019
[Gnu toolchain]
maybe this can be removed in the title?
I have updated the patch to the latest git and re-ran checks. Could somebody have a look at it please?
Nov 13 2019
Not sure what NFCI means, but for Linux the behavior should just not change at all, and the testsuite indeed behaved exactly the same on Linux indeed.
Nov 2 2019
Nov 1 2019
Here it is updated to use gnu_hurd, please commit indeed
gnu_hurd can work as well indeed
Oct 31 2019
Jan 16 2019
Any news on this?
Dec 18 2018
Right, that looks better indeed :)
Nov 28 2018
I don't have this issue with make check-all in clang/. Just to make sure: are the .keep files of the patch getting created? Otherwise the i386-gnu/ directories will not get created and then it's not surprising that clang doesn't add them to the research paths.
Nov 27 2018
I have updated the patch according to the comment.
Nov 25 2018
I have added static and shared library tests
(there still needs to be work on the test part)
I'll update the diff according to the comments.
Nov 19 2018
Here is the test for realpath extension fixed.
Nov 18 2018
(I can't commit this myself)
I have added a few checks (the ld.so dynamic linker specification, the ../lib32 paths, and /usr/lib/i386-gnu)
Nov 17 2018
I believe this version addresses all the comments.
I could run this with check-all on a linux-amd64 box.
In general when structuring your code, the performance penalty for other targets when the conditions that can be easily tested are not met should pretty much be close to nonexistent. I would suggest keeping that in mind when submitting revisions.
Nov 12 2018
Doesn't APPLE imply MACH anyway outside of targets that are way out of scope of libc++?
I have dropped the endif comment as requested.
Nov 11 2018
This includes version finding the gcc Hurd triplet (i[3456]-gnu) in the Gcc detector.
So we are back with this.
In this version, the Driver introduces the "-hurd-" part
(I can't commit this myself)
Nov 10 2018
i386-pc-hurd-gnu is fine as is, however, it seems that you want to be able to use i386-pc-gnu from Clang, if I understand correctly.
Or perhaps at least keep a Triplet::isOSHurd() which does the hurd-specific triplet parsing, instead of adding a function to clang to be used wherever we want to check for that?
I'm not sure to understand: do you mean to drop this patch entirely, so that llvm considers i386-pc-gnu as just a GNU-ish platform, and then Driver::getToolChain should special-case the Triple::UnknownOS and parse Triple::getTriple itself to call the Hurd code instead of the default toolchains::Generic_GCC case?
(as expected, I could run make check-all fine on an x86_64 linux host)
Perhaps we could go this way with additional code in cmake/config-ix.cmake, to get "hurd-gnu" as soon as possible just after detection and keep everything else inside llvm straight with llvm conventions?