mati865 added a comment.
Thank you.
Repository:
rL LLVM
https://reviews.llvm.org/D29464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL297005: Do not include GCC "resource" directory into the set
of built-in include paths… (authored by asl).
Changed prior to commit:
https://reviews.llvm.org/D29464?vs=87827&id=90661#toc
Repository:
r
mati865 added a comment.
Ping.
https://reviews.llvm.org/D29464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mati865 added a comment.
If there are no further objections it can be committed by somebody.
https://reviews.llvm.org/D29464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
asl accepted this revision.
asl added a comment.
This revision is now accepted and ready to land.
We shouldn't add resource dirs to the path. After all, these headers could use,
for example, gcc-only extensions.
https://reviews.llvm.org/D29464
___
yaron.keren added a comment.
OK.
https://reviews.llvm.org/D29464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk accepted this revision.
rnk added a comment.
So far as I can tell, Clang on Linux supports none of the headers under
discussion here, and that's been OK for some time. None of the headers in
question appear to actually work today, so I think we should remove them from
the search path.
Rega
mati865 added a comment.
Final decision is left for @rnk and @asl but I'm still against using GCC
"internal" headers in the way they aren't supposed to be used. And have MinGW
Clang behaving like Linux Clang.
> developer would have to fix the missing headers bug one day
Solving general Clang i
yaron.keren added a comment.
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
mati865 added a comment.
@yaron.keren, @rnk I would like to see OpenMP support by MinGW Clang but using
GCC "internal" headers is just wrong.
> For example, the most popular (37089 download this week)
> https://sourceforge.net/projects/mingw-w64 distribuion for Windows had
> elected to place t
yaron.keren added a comment.
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 f
rnk added a comment.
If I understand correctly, these GCC version specific include directories are
equivalent to clang's resource include directory. We shouldn't have those on
the include search path, so in principle, this seems like the right change.
https://reviews.llvm.org/D29464
___
rnk requested changes to this revision.
rnk added a comment.
This revision now requires changes to proceed.
Actually, I re-read the concerns about omp.h. We should get that ironed out
first.
https://reviews.llvm.org/D29464
___
cfe-commits mailing l
rnk accepted this revision.
rnk added a comment.
lgtm, do you need me to land this? Sorry I took a while to get around to this.
https://reviews.llvm.org/D29464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mai
mati865 added a comment.
My GPU has died in the meantime but openmp project doesn't seem buildable with
mingw-w64 based compilers.
So the case is still open.
https://reviews.llvm.org/D29464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
mati865 added a comment.
omp.h on Linux is supported by OpenMP package
https://www.archlinux.org/packages/extra/x86_64/openmp/files/
I haven't tried to build it on win32 yet but since my examination session at
college is over I'll try it in following days.
I'm not sure but openacc.h probably do
yaron.keren added a comment.
What about omp.h and openacc.h ? many programs are using OpenMP.
You raised real issues which should certainly be solved with clang mingw
support.
Removing the gcc dirs from include path will break any program that currently
uses or depends in any way on any header
mati865 marked an inline comment as done.
mati865 added a comment.
@yaron.keren those includes are not available in native Linux Clang:
float128_ex.cc:2:10: fatal error: 'quadmath.h' file not found
#include
^
And at least 2 of GCC includes clash with Clang includes:
- limits.h -
yaron.keren added a comment.
The gcc include dirs in mingw contains headers not available esewhere and thus
can't be removed.
Notable examples,
omp.h - OpenMP functions
openacc.h - OpenACC functions
quadmath.h - QUADMATH functions
https://reviews.llvm.org/D29464
__
mati865 updated this revision to Diff 87827.
mati865 added a comment.
Removed adding GCC includes for all mingw hosts.
https://reviews.llvm.org/D29464
Files:
lib/Driver/MinGWToolChain.cpp
test/Driver/mingw.cpp
Index: test/Driver/mingw.cpp
===
asl requested changes to this revision.
asl added inline comments.
This revision now requires changes to proceed.
Comment at: lib/Driver/MinGWToolChain.cpp:211
+#ifndef LLVM_ON_WIN32
if (GetRuntimeLibType(DriverArgs) == ToolChain::RLT_Libgcc) {
This check is
mati865 added a comment.
I know why mingw-w64 limits.h weren't used (check first comment).
At first I was using this hack:
diff -urN clang.orig/3.9.0/include/limits.h clang/3.9.0/include/limits.h
--- clang.orig/3.9.0/include/limits.h 2016-09-26 22:29:13.496441000 +0200
+++ clang/3.9.0/inclu
yaron.keren added a comment.
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.
The reason mingw limits.h isn't used in your example is tha
mati865 added a comment.
Adding
// c:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include
// c:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include-fixed
for Clang is wrong on Windows because including limits.h will not show an error
and won't really include mingw-w64 limits.h
Output of code from my
yaron.keren added a comment.
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.
Please make sure include dirs between gcc and clang match after the patch
mati865 added a comment.
I don't know about Linux but on Windows this code was causing issue:
#include
int main() { char buf[PATH_MAX]; }
Include order:
- Before patch: Clang limits.h (lib\\clang\\3.9.1\\include) -> GCC limits.h
(lib\\gcc\\x86_64-w64-mingw32\\6.3.0\\include-fixed) here wh
mati865 created this revision.
mati865 added a project: clang-c.
Header guards in GCC limits.h were stopping Clang from going up one more level
to the system limits.h
https://reviews.llvm.org/D29464
Files:
lib/Driver/MinGWToolChain.cpp
Index: lib/Driver/MinGWToolChain.cpp
=
27 matches
Mail list logo
