Author Topic: Clang integration? (Read 35756 times)

infinigon · « **on:** October 24, 2010, 09:24:07 pm »

Are there any plans for integrating Code::Blocks with Clang? I've only looked over it briefly, but it looks to integrate much more tightly with IDE's, like aiding with static code analysis and transformation
http://clang.llvm.org/features.html#applications

Also, I don't know whether Clang's AST could benefit Code::Blocks' code-completion redesign?

ollydbg · « **Reply #1 on:** October 25, 2010, 01:36:57 am »

Not sure How hard to integrate Clang to codeblocks.

Quote

Currently, clang is divided into the following libraries and tool:

* libsupport - Basic support library, from LLVM.
* libsystem - System abstraction library, from LLVM.
* libbasic - Diagnostics, SourceLocations, SourceBuffer abstraction, file system caching for input source files.
* libast - Provides classes to represent the C AST, the C type system, builtin functions, and various helpers for analyzing and manipulating the AST (visitors, pretty printers, etc).
* liblex - Lexing and preprocessing, identifier hash table, pragma handling, tokens, and macro expansion.
* libparse - Parsing. This library invokes coarse-grained 'Actions' provided by the client (e.g. libsema builds ASTs) but knows nothing about ASTs or other client-specific data structures.
* libsema - Semantic Analysis. This provides a set of parser actions to build a standardized AST for programs.
* libcodegen - Lower the AST to LLVM IR for optimization & code generation.
* librewrite - Editing of text buffers (important for code rewriting transformation, like refactoring).
* libanalysis - Static analysis support.
* libindex - Cross-translation-unit infrastructure and indexing support.
* clang - A driver program, client of the libraries at various levels.

seems: librewrite can support code refactoring.

infinigon · « **Reply #2 on:** October 29, 2010, 02:51:41 pm »

Eh, I just found this from about a year ago:
http://forums.codeblocks.org/index.php?topic=11268.0

Sorry about the redundancy (note to self: GIYF), but still, this would be useful to have, especially for the future as Clang becomes more mature and capable.

reckless · « **Reply #3 on:** November 11, 2010, 03:40:46 am »

made a build of llvm/llvm-gcc svn and binutils.

includes native python and gdb.

ftp://90.184.233.166:21/LLVM.7z

can be used with msys also if you add the folder to fstab instead of the normal mingw.
like so C:/LLVM. /mingw

for msys autotool based builds you might have to tell the autotools what C and C++ compilers to use like this CC=llvm-gcc CXX=llvm-g++

mingw32-make is not included but the one from mingw site works just fine.

only handles c/c++ and fortran atm. ada cannot be built with gcc-4.5.1 i use to bootstrap as the version of gcc from llvm is a rather ancient one 4.2.1

ollydbg · « **Reply #4 on:** November 11, 2010, 03:48:54 am »

Quote from: reckless on November 11, 2010, 03:40:46 am

made a build of llvm/llvm-gcc svn and binutils.

includes native python and gdb.

ftp://90.184.233.166:21/LLVM.7z

can be used with msys also if you add the folder to fstab instead of the normal mingw.
like so C:/LLVM. /mingw

for msys autotool based builds you might have to tell the autotools what C and C++ compilers to use like this CC=llvm-gcc CXX=llvm-g++

mingw32-make is not included but the one from mingw site works just fine.

only handles c/c++ and fortran atm. ada cannot be built with gcc-4.5.1 i use to bootstrap as the version of gcc from llvm is a rather ancient one 4.2.1

So, this is a full package that can replace the mingw-gcc ??

Edit: it was 120M + .... to big...

BTW:
the link should be fixed to:

ftp://90.184.233.166:21/LLVM.7z

reckless · « **Reply #5 on:** November 11, 2010, 03:53:10 am »

yep noticed fixed the link

if you only need c/c++ or fortran support it can replace the standard mingw.

there are a few quirks to get codeblocks running with it for one gcc and g++ are prefixed with llvm- so need to tell it that. the same goes for gfortran.

sorry about the size ill see if i can hammer it down some but this is mostly a test build.

Jenna · « **Reply #6 on:** November 11, 2010, 07:46:34 am »

Did you enable optimization ?
Otherwise, you create a debug-build and that's mauch larger (and slower).

There is switch for the configure-script, I don't know exactly how it is named (not on my system), but I guess it was --enable-optimization.
Search for it with ./configure --help .

If you use makefiles directly, the switch is named ENABLE_OPTIMIZED=1 .

reckless · « **Reply #7 on:** November 11, 2010, 09:46:38 am »

aye was set as debug compiling a release version now

should be up in some hours unless i run into problems.

joubertdj · « **Reply #8 on:** November 11, 2010, 10:11:35 am »

For those of you who don't know ... Clang has successfully compiled the Linux Kernel ... hmmm ...
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html ... whoop ...

ollydbg · « **Reply #9 on:** November 11, 2010, 12:22:24 pm »

Quote from: joubertdj on November 11, 2010, 10:11:35 am

For those of you who don't know ... Clang has successfully compiled the Linux Kernel ... hmmm ...
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html ... whoop ...

great compiler!!!

I have one glance on the source code of clang's lexer and parser. it was quite (too) complex. All the lexer/ parser was hand-written. and their hand-written lexer doesn't distinguish with any identifiers and keyword. instead, they use an identifier hash table, once the lexer get a general identifier, it will be looked up in the identifier table to see if it was a keyword or a macro definition or a new real identifier...

the code snippet of parsing a function declaration was more than 800 lines. :shock:

reckless · « **Reply #10 on:** November 11, 2010, 12:54:10 pm »

its good

but a major pain in the beep beep! to compile.

the gcc to bootstrap it has neither thread nor exception support so im bootstrapping my version with gcc-4.5.1 and while it does seem to work for c/c++ and fortran ada barfs loudly because the ada compiler changed a lot from the 4.2 version (bad casing of NUL) error.

also bootstrapping the gcc 4.2 compiler seems to run out of stack space (pthread bug i suspect) so can only make a none bootstrapped gcc for the moment.

theres been some work to use gcc's plugin system with a plugin called dragonegg to use the llvm compiler with unmodified gcc 4.5. unfortunatly its linux/mac only atm so were stuck with the old gcc for the moment.

Jenna · « **Reply #11 on:** November 11, 2010, 12:59:48 pm »

Please keep in mind, that this is the C::B forum, not the clang/llvm forum.

reckless · « **Reply #12 on:** November 11, 2010, 01:34:04 pm »

ofc. jens sorry about that.

still building so ill post when theres a new release for those who want to try it with cb.

reckless · « **Reply #13 on:** November 12, 2010, 03:12:55 am »

ok new version up, same download link.

ollydbg · « **Reply #14 on:** November 12, 2010, 03:17:02 am »

Quote from: reckless on November 12, 2010, 03:12:55 am

ok new version up, same download link.

strange, when I click on the ftp link, it opened a folder... (windows firefox)

reckless · « **Reply #15 on:** November 12, 2010, 04:24:04 am »

hmm havent changed anything on my ftp ? try pasting the url directly.

ollydbg · « **Reply #16 on:** November 12, 2010, 04:46:48 am »

Quote from: reckless on November 12, 2010, 04:24:04 am

hmm havent changed anything on my ftp ? try pasting the url directly.

the url becomes like this in my firefox address bar:

Code

ftp://90.184.233.166/LLVM.7z/

this is a folder...

reckless · « **Reply #17 on:** November 12, 2010, 08:02:51 am »

should be ftp://90.184.233.166:21/LLVM.7z

not sure why it changed though.

uploading a shared build with thread and exception support in a short.

new build uses pthreads for threading.

ill probably apply johns patchset to the llvm-gcc backend to get the exception handling working on static builds.

ollydbg · « **Reply #18 on:** November 12, 2010, 09:29:25 am »

I still show a folder. see the screen shot.

reckless · « **Reply #19 on:** November 12, 2010, 10:29:06 am »

no idea why that happens tbh. i just had one of my mates try and download it and he had no problem so im a bit lost.

which browser do you use ? personally i use firefox and it works here.

btw shared build is done ftp://90.184.233.166:21/LLVM-shared.7z latest svn version.

reckless · « **Reply #20 on:** November 12, 2010, 10:31:14 am »

uploading the package to my google code site should be downloadable from there.

edit: is up now.

reckless · « **Reply #21 on:** November 13, 2010, 06:18:33 am »

preliminary testing suggests that it might work with codeblocks allthough the linking stage fails. as far as i could read into it its because the parsing is done differently (linker cant determine the type of the object files).

it works fine with msys so far.

feel free to use my provided package if you intend on adding support for llvm in codeblocks.

meanwhile ill look at what changes will be nessesary to get dragonegg working with win32 mingw.

ollydbg · « **Reply #22 on:** December 09, 2010, 06:42:29 am »

@reckless
I just use this package
ftp://90.184.233.166/LLVM-shared.7z

and configure in codeblocks like below:

then, I just using the wizard to create a console hello world project.

but it failed on compiling...

Code


-------------- Build: Debug in buildllvmgcctest ---------------

[ 50.0%] llvm-g++.exe -Wall -fexceptions  -g     -c F:\cb\testCode\buildllvmgcctest\main.cpp -o obj\Debug\main.o
[100.0%] llvm-g++.exe  -o bin\Debug\buildllvmgcctest.exe obj\Debug\main.o    
F:\cb\testCode\buildllvmgcctest\main.cpp:1:20: error: iostream: No such file or directory
F:\cb\testCode\buildllvmgcctest\main.cpp: In function 'int main()':
F:\cb\testCode\buildllvmgcctest\main.cpp:7: error: 'cout' was not declared in this scope
F:\cb\testCode\buildllvmgcctest\main.cpp:7: error: 'endl' was not declared in this scope
Process terminated with status 1 (0 minutes, 0 seconds)
3 errors, 0 warnings (0 minutes, 0 seconds)

Do I need to manually add the include search patch??

thanks.

ollydbg · « **Reply #23 on:** December 09, 2010, 06:49:39 am »

by the way, you just hard-coded the path??

see the log below when I run the command:

Quote

F:\cb\llvm_gcc\LLVM\bin>llvm-gcc -v -x c++ nul -fsyntax-only
Using built-in specs.
Target: i386-mingw32
Configured with: ../llvm-gcc-4.2/configure --prefix=/llvm --host=i386-mingw32 --
build=i386-mingw32 --enable-languages=c,c++,fortran --disable-nls --disable-mult
ilib --disable-win32-registry --disable-werror --disable-bootstrap --disable-sym
vers --program-prefix=llvm- --enable-llvm=/home/ralph/llvm-objects --enable-full
y-dynamic-string --with-gxx-include-dir=/llvm/include/c++/4.2.1 --with-sysroot=/
usr
Thread model: win32
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
f:/cb/llvm_gcc/llvm/bin/../libexec/gcc/i386-mingw32/4.2.1/cc1plus.exe -quiet -v
-iprefix f:\cb\llvm_gcc\llvm\bin\../lib/gcc/i386-mingw32/4.2.1/ nul -quiet -dum
pbase nul -mtune=i386 -auxbase nul -version -fsyntax-only -o nul
ignoring nonexistent directory "f:/cb/llvm_gcc/llvm/bin/../lib/gcc/i386-mingw32/
4.2.1/../../../../i386-mingw32/include"
ignoring nonexistent directory "c:/codeblocks/llvm/include/c++/4.2.1"
ignoring nonexistent directory "c:/codeblocks/llvm/include/c++/4.2.1/i386-mingw3
2"
ignoring nonexistent directory "c:/codeblocks/llvm/include/c++/4.2.1/backward"
ignoring nonexistent directory "C:/CodeBlocksc:/codeblocks/llvm/lib/gcc/i386-min
gw32/4.2.1/../../../../include"
ignoring nonexistent directory "c:/codeblocks/llvm/lib/gcc/i386-mingw32/4.2.1/in
clude"
ignoring nonexistent directory "c:/codeblocks/llvm/i386-mingw32/include"
ignoring nonexistent directory "C:/CodeBlocks/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
f:/cb/llvm_gcc/llvm/bin/../lib/gcc/i386-mingw32/4.2.1/include
End of search list.
cc1plus.exe: warning: nul.gch: too short to be a PCH file
GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build) (i386-mingw3
2)
compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM b
uild).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
Compiler executable checksum: 5faebdeec4705890ed271b3e78d3baee
nul:1: warning: 'nul.gcda' is not a gcov data file

F:\cb\llvm_gcc\LLVM\bin>

it seems all the path was something like: "c:/codeblocks/llvm"....., but that does not work on my system, can this be relocatable?

reckless · « **Reply #24 on:** December 10, 2010, 09:50:08 pm »

ah aye i suspected something like that and no not atm else it wont build as pr the instructions on the llvm site

ill see if i can patch something up.

reckless · « **Reply #25 on:** December 13, 2010, 03:28:45 am »

btw untill i get the gcc build fixed you can use the llvm-gcc from llvm site. unfortunatly it doesnt include gfortran but atleast it seems to work relocatable.

reckless · « **Reply #26 on:** December 13, 2010, 01:38:49 pm »

new build up on google code.

patched with some of john's older patches for gcc-4.2.1.

it took a war getting it to recognize the c++ directory (wont bootstrap unless the llvm dir is named mingw and in the root) but it seems to compile fine in any dir after its built now.

ollydbg · « **Reply #27 on:** December 13, 2010, 02:04:01 pm »

Quote from: reckless on December 13, 2010, 01:38:49 pm

new build up on google code.

patched with some of john's older patches for gcc-4.2.1.

it took a war getting it to recognize the c++ directory (wont bootstrap unless the llvm dir is named mingw and in the root) but it seems to compile fine in any dir after its built now.

thanks, but why the package is 94M, so large??

http://code.google.com/p/mingw-wine/downloads/detail?name=LLVM.rar&can=2&q=

reckless · « **Reply #28 on:** December 13, 2010, 02:48:32 pm »

winrar isn't as good at compressing

also the svn version i built this from gained some extra libraries so it is indeed a bit bigger.

reckless · « **Reply #29 on:** December 13, 2010, 02:51:43 pm »

oh before i forget still not working with codeblocks :S the linker crashes with ntdll error.

i have no idea why since it works fine if done from commandline.

reckless · « **Reply #30 on:** December 13, 2010, 06:07:54 pm »

i made a patch against latest svn version including john's patchset and a fix for compiling gfortran.

http://mingw-wine.googlecode.com/files/llvm-gcc.patch

reckless · « **Reply #31 on:** December 14, 2010, 10:42:27 am »

ok seems i got a stable development version now.

next version will have some small changes.

replacing the mingw64 api with the standard mingw w32api since the gcc used as frontend is to ancient to use the mingw64 intrinsics.
compile against the static gmp and mpfr libraries link problems otherwise.
link against static iconv (winiconv in this case).

get a hold on the llvm-gcc patchset to update it for latest gcc (kinda needed for win32 atm since the dragonegg plugin for gcc-4.5 only works on unix and darwin).
the above might not be needed since the real build is done with the clang compiler (gcc only used to create the bytecode) i might be wrong though.

some things to consider.

the llvm compiler wont work unless the bin dir is on PATH (cannot find its headers otherwise).
codeblocks compatibility. atm it crashes when linking while it works from commandline (not really sure what tool clang uses for linking. atm i use clang++).
bootstrapping is broken. xgcc out of memory on second stage. if anyone got a fix let me hear.

reckless · « **Reply #32 on:** December 14, 2010, 08:17:04 pm »

ok final version up.

replaced the w32api with standard mingw one and recompiled everything.
added ccache and some shellscripts to run gcc and g++ through it if you use msys.
built against winiconv.
fortran c/c++ fully working ada was left out since it wont build (tried every trick in the book and out of it).
binutils and llvm-make built with it so yes it does work

the 7zip file includes everything needed.

remember the compilers bin dir must be on PATH or it wont find its headers/libraries.

reckless.

reckless · « **Reply #33 on:** December 15, 2010, 08:23:46 am »

small update.

codelite works with llvm :shock:

and now for something really really bad.

johns patchset while definatly ok for standard mingw unfortunatly breaks llvm-gcc

im reverting the parts that break now sorry about that.

ill upload the fixed llvm-gcc compiler standalone so atleast you wont have to redownload the entire thing just unzip it over the old one.

reckless · « **Reply #34 on:** December 15, 2010, 12:46:47 pm »

another baddy llvm-gcc cannot build dll's due to a bug with __declspec(dllexport) so only static builds work atm. the bug is known but i cannot tell the timeframe for any fix as most development seems to target the dragonegg plugin these days so there might newer be a fix.

ollydbg · « **Reply #35 on:** December 15, 2010, 01:13:32 pm »

you have already done a great work!!!

reckless · « **Reply #36 on:** December 15, 2010, 01:46:05 pm »

yeah i guess i can rest a bit

ill try new builds from time to time to see if the __declspec bug is fixed if it is ill let you know

reckless · « **Reply #37 on:** December 15, 2010, 06:39:57 pm »

before i quit for today.

http://code.google.com/p/mingw-wine/downloads/detail?name=LLVM-gcc-only.7z&can=2&q=

the reverted llvm-gcc.

Halan · « **Reply #38 on:** May 22, 2012, 01:29:48 pm »

Just wondering. Is anybody still working on Clang-Support?

In current nightly I can only use LLVM for compiling D code.

MortenMacFly · « **Reply #39 on:** May 22, 2012, 01:46:35 pm »

Quote from: Halan on May 22, 2012, 01:29:48 pm

Just wondering. Is anybody still working on Clang-Support?

What exacly do you mean? If you use the GCC "wrapper", provided in this thread you can so it already.
All that needs to be done is to make a copy of the GCC compiler, name it LLVM (or alike), adjust the toolchain executable names, maybe fiddle with some compiler options (same as on command line) and your are done.

EDIT: I am using this btw:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/experimental/

reckless · « **Reply #40 on:** May 23, 2012, 09:22:43 am »

I long since ditched the old llvm-gcc and instead added dragonegg support to mingw (latest version with dragonegg on my site is 4.6.3) thanks to xunxun for the initial work.
Its a bit different than dragonegg on linux as each compiler has its own plugin.
Elaborating for C use -fplugin=dragonegg-cc1 for C++ use -fplugin=dragonegg-cc1plus etc.
It works fine most of the time but in a few cases i ran into problems linking stuff when the plugin was enabled, in that case add -Wl,--allow-multiple-definition to the linker flags.

News:

Author Topic: Clang integration? (Read 35756 times)