User Details
- User Since
- Oct 9 2013, 1:30 PM (485 w, 1 d)
Feb 17 2022
Git for Windows comes with its own installation of a bunch of them, and llvm's lit does pick them up automatically if they aren't available in PATH: https://github.com/llvm/llvm-project/blob/main/llvm/utils/lit/lit/llvm/config.py#L31-L35
Sep 6 2021
Yes the test had passed since then, so all OK.
Aug 31 2021
Addressing comment in https://reviews.llvm.org/D108085
Aug 27 2021
Aug 26 2021
Thanks for all the comments!
The x64 windows pre-check bot is failing on this test, see:
Upload lal local commits to include all local changes
Aug 24 2021
Address comments
Aug 21 2021
Trying yet again to fix the diff
Trying to fix the diff
Fix typo
add all commits
Aug 20 2021
I completely agree, the Getting Started document should be modernized considering a current Visual Studio 2019 installation bundles tools and that GnuWin32 is antique. I will create revision for your review.
Aug 19 2021
Aug 18 2021
already fixed in https://github.com/llvm/llvm-project/commit/ffe58de39319b42b46319473263b59bd68ceee67
passes tests
Aug 17 2021
Switched to Linux repo
opened by mistake
Aug 15 2021
Support both Windows llvm-lit.py and Linux llvm-lit command name
looking into Linux failures
Oct 7 2019
Feb 28 2018
Jun 12 2017
Added test in r305213.
Jun 11 2017
Apr 27 2017
OK
Raphael , do you have commit access? should I commit this?
Apr 25 2017
LGTM
Please move the =new out of the PP.AddPragmaHandler calls.
While at it, this code still (as the original) leaks the PragmaHandlers. These should be deleted after RemovePragmaHandler or instead, simply use std::unique_ptr.
Apr 17 2017
reverted in r300497
Apr 14 2017
Adding Mateusz and Reid.
Apr 12 2017
Added attribute test.
Apr 5 2017
Thanks, I'll make a test.
Mar 31 2017
Mar 30 2017
Mar 29 2017
No intention of any major work intended... just moved the code (locally) to Release and regression tests were still passing.
Most other module flags are added at CodeGenModule::Release(). For consistency, could this code be in CodeGenModule::Release() as well?
Mar 21 2017
Could use dumpDeclContext() to test?
Feb 14 2017
OK.
If something is broken now we don't break it even more.
__float128 remain be fixed to be compatible, not only some poor developer would have to fix the missing headers bug one day, he will have to re-fix limits.h the right way and undo this "fix".
There is a problems with limits.h, fix limits.h. Don't make all headers that happens to be in the same directory as limits.h disappear.
Feb 13 2017
These directories are "mostly" equivalent, with some headers existing is mings gcc dir but missing in clang resource dir and thus will break compilation.
For example, the most popular (37089 download this week) https://sourceforge.net/projects/mingw-w64 distribuion for Windows had elected to place the includes
omp.h, quadmath.h, openacc.h
at
c:\mingw32\lib\gcc\i686-w64-mingw32\5.4.0\include\
with the corresponding libraries at
c:\mingw32\lib\gcc\i686-w64-mingw32\5.4.0\
I had verified this still holds true for the latest i686-6.3.0-release-posix-dwarf-rt_v5-rev1.7z package.
Removing the include dir will make clang less useful for mingw users using these includes, since they will not be found anymore.
Furthermore, It makes no sense to make such intrusive wide-ranging change where the original problem was with limits.h is actually due to:
/* The system's limits.h may, in turn, try to #include_next GCC's limits.h. Avert this #include_next madness. */ #if defined __GNUC__ && !defined _GCC_LIMITS_H_ #define _GCC_LIMITS_H_ #endif
so the solution may be as simple as
#if defined __GNUC__ && !defined _GCC_LIMITS_H_ && !defined __MINGW32__ #define _GCC_LIMITS_H_ #endif
Feb 9 2017
What about omp.h and openacc.h ? many programs are using OpenMP.
The gcc include dirs in mingw contains headers not available esewhere and thus can't be removed.
Notable examples,
Feb 3 2017
Hiding these two include dirs removes many headers. Most has clang equivalents but not all of them.
For example quadmath.h is only there, and without the include path programs using it will fail to compile.
This code is actually used with Windows as well as Linux (with the exception of line 218), see the comment blocks above for detailed include dirs from all platforms from which it was derived.
Jan 21 2017
LGTM, matches the code in libstdc++ stdarg,h.
You can remove the 'hack' comment in line 46, __GNUC_VA_LIST is just a standard include guard for the typedef.
Jan 12 2017
Jan 6 2017
While at it, http://llvm.org/pr30994
Dec 29 2016
Dec 12 2016
Nov 29 2016
LGTM after fixing the inline comment
Nov 26 2016
Jul 28 2016
PR28749 was created with trunk clang on Ubuntu x64.
It reproduced reliably but is very fragile, changing just about anything in the code makes the problem disappear.
Jul 27 2016
I added a small reproducer for what is probably the same problem in
Jun 8 2016
You mean
Some target platforms do not support -fsanitize=address.
May 13 2016
result of r269402, LGTM
Apr 20 2016
Ah, OK, I am using regular svn and thus did not counter this problem.
Could you detail this exactly, the problem happens when using git-svn with core.autocrlf config=true but not with svn?
LGTM with this addition.
AFAIK the eol type is decided by svn based the svn:eol-style property, so as long the files were checked in correctly and you do not override it specifically while svn checkout, it just works.
Did you encounter problems with eol ?
Feb 17 2016
Would be nice to have CodeGenAction::TheModule redirect to CodeGeneratorImpl::M if possible, but that's for another patch. LGTM.
It certainly makes sense to redirect the module request to its owner instead of duplicating it in a local copy.
Feb 11 2016
We have tried to keep one copy of DataLayout around
http://reviews.llvm.org/D11103
Can it share the Module->getDataLayout() ?
Jan 28 2016
The instantiated does get a new collection of ParmVarDecls while getting
the pattern Type which points to the pattern ParmVarDecls. So the
ParmVarDecls pointed in the instantiated are not the same as those pointed
by its Type.
Dec 18 2015
#define NOGDI
is also useful.
+1 all general-purpose Windows stuff should move to WindowsSupport.h. I'm surprised we got away without so far.
We have NOMINMAX at lib/Driver/MSVCToolChain.cpp before Windows.h which should probably switched to use WindowsSupport.h.