Re: [Mesa-dev] cflags mess with llvm builds
On Sat, Sep 25, 2010 at 12:24 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 11:36 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) The first answer is very negative and reports the bug as invalid. http://llvm.org/bugs/show_bug.cgi?id=8220#c1 The only suggestion is that custom flags could be appended. Another problem is indeed that mesa puts these llvm flags at the end, and the custom user CFLAGS first. Normally you do that because if the user has custom include paths, you want them to be at the beginning of the command line. It'd be nice if the llvm people could just use pkg-config instead of rolling their own config tool. I thought people had stopped doing that by now. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 11:36 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) The first answer is very negative and reports the bug as invalid. http://llvm.org/bugs/show_bug.cgi?id=8220#c1 The only suggestion is that custom flags could be appended. Another problem is indeed that mesa puts these llvm flags at the end, and the custom user CFLAGS first. irc discussion on oftc #llvm : 18:16 shining^ hopefully someone will look at http://llvm.org/bugs/show_bug.cgi?id=8220 , it should be easy to fix 18:16 gccbot tools bug #8220: llvm-config prints unnecessary cflags Product: tools, Component: llvm-config, Severity: normal, Assigned to: unassignedbugs, Status: NEW 18:20 @ aKor shining^: the PR looks invalid to me. 18:20 @ aKor shining^: all the printed tools are also required for projects 18:21 @ aKor e.g. sometimes O3 is lowered to O2 to workaround compiler miscompilation 18:21 @ aKor if you want to override the settings, you should just append the necessary stuff to the end of cflags / cxxflags 18:54 shining^ aKor: why are they required for projects ? 18:56 @ aKor shining^: because in the projects decent amount of LLVM code is compiled and used. This is mostly the code coming from the headers. 18:57 shining^ I dont think the purpose of that tool is to workaround compiler bugs. its just to provide the minimum set of flags required to build llvm code. maybe there isnt actually any ? 18:58 @ aKor well, if -O2 is *required* to workaround compiler bugs, then it's surely should be included into minimal set of options 18:58 @ aKor (as opposed to -O3) 18:59 shining^ otherwise we need both a minimum set of flags and an optimal set , working around bugs and all 18:59 shining^ why -O2 or -O3 ? maybe I dont want any 19:00 @ aKor ok, then just override it 19:00 @ aKor -O2 -O0 will yield -O0 19:00 shining^ well, its indeed very problematic in mesa, since these flags are appended last :P 19:01 @ aKor then the problem is in mesa's build system :) 19:01 shining^ so my CFLAGS=-O0 settings didnt work at all. I suppose I will go back to mesa people then .. 19:01 shining^ which is where I reported the problem in the first place, of course 19:01 @ aKor in the list in PR only -fomit-frame-pointer -fPIC are redundant 19:02 ddunbar_ shining^: fwiw, I agree with you the -O doesn't belong there 19:02 ddunbar_ or we should have two sets 19:02 @ aKor ddunbar_: it depends on the platform and compiler used 19:02 shining^ well -fomit-frame-pointer annoyed me too, I specifically build with no-omit-frame-pointer so I can get useful profiles 19:04 ddunbar_ aKor: I agree with the principle that it there should be a way to just get the required flags 19:05 @ aKor one should just define required, e.g. required to just build or required to build usable binaries. The latter seems should include more flags :) 19:05 ddunbar_ not that many 19:05 ddunbar_ I think the -D_GNU belong, and -frtti perhaps, but not much more 19:07 @ aKor ddunbar_: rtti settings should always be required, otherwise link will fail 19:07 ddunbar_ which is why I mentioned it :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] cflags mess with llvm builds
When gallium llvm is enabled, configure.ac does the following : LLVM_CFLAGS=`$LLVM_CONFIG --cflags` This is the result on my system : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC I specifically set -O0 to easier gdb debugging and -fno-omit-frame-pointer to use some profiling tools, but they were both silently overridden by llvm cflags. Also scons/llvm.py only uses cppflags, not cflags, which at least gives a better result llvm-config --cppflags : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS then src/gallium/Makefile.template has : ifeq ($(MESA_LLVM),1) LIBRARY_DEFINES += $(LLVM_CFLAGS) endif Do we want / need these definitions for all the code in src/gallium, or is it possible to add them only in the parts that do use llvm and need the definitions from llvm-config --cppflags ? I found it weird that enabling or disabling gallium llvm resulted in nv50 gallium built with different gcc flags. From df82cdf0b9b6bd60ef47ddbf4b6d74d200382262 Mon Sep 17 00:00:00 2001 From: Xavier Chantry chantry.xav...@gmail.com Date: Fri, 24 Sep 2010 13:17:40 +0200 Subject: [PATCH] configure.ac : use llvm-config cppflags instead of cflags llvm cflags are too intrusive and override user-defined flags. cppflags are probably enough and this is what scons/llvm.py uses already. $ llvm-config --cflags -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC $ llvm-config --cppflags -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 2b8296d..c88ee5e 100644 --- a/configure.ac +++ b/configure.ac @@ -1439,7 +1439,7 @@ AC_ARG_ENABLE([gallium-llvm], if test x$enable_gallium_llvm = xyes; then if test x$LLVM_CONFIG != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` - LLVM_CFLAGS=`$LLVM_CONFIG --cflags` + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags` LLVM_LIBS=`$LLVM_CONFIG --libs jit interpreter nativecodegen bitwriter` -lstdc++ if test x$HAS_UDIS86 != xno; then -- 1.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 14:06:51 +0200, Xavier Chantry wrote: When gallium llvm is enabled, configure.ac does the following : LLVM_CFLAGS=`$LLVM_CONFIG --cflags` This is the result on my system : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC I'd argue that that's a bug in llvm-config, it has no business telling you what optimisation level to use, or defining random macros. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) It's still strange to have scons use --cppflags and autotools --cflags. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
