search for: llvm_

Hi all, I would like to rename LLVM_ATTRIBUTE_READONLY to LLVM_READONLY and LLVM_ATTRIBUTE_READNONE to LLVM_READNONE Any objections? - Daniel

What's the reason for renaming them? -bw On Mar 8, 2012, at 4:57 PM, Daniel Dunbar wrote: > Hi all, > > I would like to rename > LLVM_ATTRIBUTE_READONLY to LLVM_READONLY > and > LLVM_ATTRIBUTE_READNONE to LLVM_READNONE > > Any objections? > > - Daniel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://li...

...renaming them? I can think of two things: 1) it being an attribute is an implementation detail 2) it being long makes it annoying to use :) -Chris > > -bw > > On Mar 8, 2012, at 4:57 PM, Daniel Dunbar wrote: > >> Hi all, >> >> I would like to rename >> LLVM_ATTRIBUTE_READONLY to LLVM_READONLY >> and >> LLVM_ATTRIBUTE_READNONE to LLVM_READNONE >> >> Any objections? >> >> - Daniel >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu htt...

...e is an implementation detail > 2) it being long makes it annoying to use :) Exactly. - Daniel > -Chris > >> >> -bw >> >> On Mar 8, 2012, at 4:57 PM, Daniel Dunbar wrote: >> >>> Hi all, >>> >>> I would like to rename >>> LLVM_ATTRIBUTE_READONLY to LLVM_READONLY >>> and >>> LLVM_ATTRIBUTE_READNONE to LLVM_READNONE >>> >>> Any objections? >>> >>> - Daniel >>> _______________________________________________ >>> LLVM Developers mailing list >>>...

Being fully aware that llvmc2 is work-in-progress, here are some notes nethertheless: I already compiled llvm, but llvm-gcc was still compiling. Now I tried the new llvmc2: $ llvmc2 -opt -v main.c llvm-g++ -c -x c main.c -o /tmp/llvm_KeApik/main.bc -emit-llvm llvmc2: Can't find program 'llvm-g++' * after this, the directory /tmp/llvm_KeApik was not removed * why using /tmp at all? And if, why /tmp/llvm_* and not /tmp/llvmc2_* ? * why calling "llvm-g++ -x c" and not "llvm-gcc" ? * a --dry-run...

...(the main author) sometimes cannot catch the mailing list directly, so please, CC him also (foldr at codedgers.com) I'll try to answer some questions and Mikhael will try to resolve others. > * why using /tmp at all? Same does gcc, we don't have pipe option yet. > And if, why /tmp/llvm_* and not /tmp/llvmc2_* ? Well, llvm_ - because we're using general LLVM routines for generation of temp filenames, which use "llvm" prefix. > All of this is based on LLVM SVN 51761. What is your platform? -- WBR, Anton Korobeynikov

I just built a stage-1 compiler from the 3.9 release bits and built the lldb from head sources which worked fine. Let me try again using 3.9 build compiler to build 3.9 bits. Teresa On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com> > wrote: > >> On

...and ``bugpoint``. One first needs to create an independent project and add it to either ``tools/`` or, using the MonoRepo layout, at the root of the repo alongside other projects. This project must contain the following minimal ``CMakeLists.txt``: .. code-block:: cmake add_llvm_pass_plugin(Name source0.cpp) The pass must provide two entry points for the new pass manager, one for static registration and one for dynamically loaded plugins: - ``llvm::PassPluginLibraryInfo get##Name##PluginInfo();`` - ``extern "C" ::llvm::PassPluginLibraryInfo llvmG...

...I'd check before just going and doing it. 1. Various autoconf generated variables (e.g. abs_top_srcdir) are set in the makefiles but not used. They conflict with a user's project that might want to use them. I propose removing them or using names prefixed with llvm_ to ensure their use is only for llvm 2. BUILD_SRC_DIR and BUILD_OBJ_DIR are poorly named. This has been a source of confusion for me personally and probably for others. They should really be PROJ_SRC_DIR and PROJ_OBJ_DIR to indicate they pertain to the project...

...ef sparc > #undef INT64_MAX > #undef alloca > > This is not OK to do globally -- even if LLVM doesn't care about the > definition, maybe embedding applications or OS headers do? > > $ find include -iname '*.h' | xargs grep '^#' -- | grep -vE > '^.*:.*(LLVM_|cplusplus|endif|else|include|define )'| grep -vw Support | wc > -l > *57* > > I think it's perfectly realistic to get that number down to 0. > > We can start by putting a check like that in the build system, first to > emit a warning, and ultimately to make violat...

...t going and doing it. > > 1. Various autoconf generated variables (e.g. abs_top_srcdir) are > set in the makefiles but not used. They conflict with a user's > project that might want to use them. I propose removing them or > using names prefixed with llvm_ to ensure their use is only for > llvm > 2. BUILD_SRC_DIR and BUILD_OBJ_DIR are poorly named. This has been > a source of confusion for me personally and probably for others. > They should really be PROJ_SRC_DIR and PROJ_OBJ_DIR to indicate > they...

...gt; most cases these are just historical artifacts that have been with the > > projects since long before the new Makefile.rules of last fall. > > I agree. Okay, I'll make that happen :) > >> llvm/Makefile.config.in have lines: > >> > >> INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh > >> MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs > >> > >> But all this projects (LLVM, Stacker, sample, llvm-java) have > >> autoconf/install-sh and autoconf/mkinstalldirs in own sources. > > > > Which they prob...

...for /F "tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr "_LLVM"') do (set symbolname=%e & echo !symbolname:~1!))" What it does: For all *.lib files ina specific dir starting with LLVM call dumpbin.exe (tool from Visualstudio) and write all symbols with LLVM_ into a specific file 2017-04-05 20:40 GMT+02:00 Jakob Bornecrantz via llvm-dev < llvm-dev at lists.llvm.org>: > On Wed, Apr 5, 2017 at 5:20 PM, John Brawn <John.Brawn at arm.com> wrote: > > We already half-have this, the LLVM_BUILD_LLVM_C_DYLIB cmake option > builds > &...

...t going and doing it. > > 1. Various autoconf generated variables (e.g. abs_top_srcdir) are > set in the makefiles but not used. They conflict with a user's > project that might want to use them. I propose removing them or > using names prefixed with llvm_ to ensure their use is only for > llvm > 2. BUILD_SRC_DIR and BUILD_OBJ_DIR are poorly named. This has been > a source of confusion for me personally and probably for others. > They should really be PROJ_SRC_DIR and PROJ_OBJ_DIR to indicate > they...

...; > > > 1. Various autoconf generated variables (e.g. abs_top_srcdir) are > > set in the makefiles but not used. They conflict with a user's > > project that might want to use them. I propose removing them or > > using names prefixed with llvm_ to ensure their use is only for > > llvm > > 2. BUILD_SRC_DIR and BUILD_OBJ_DIR are poorly named. This has been > > a source of confusion for me personally and probably for others. > > They should really be PROJ_SRC_DIR and PROJ_OBJ_DIR to indica...

...BSD|| ||#undef mips|| ||#undef sparc|| ||#undef INT64_MAX|| ||#undef alloca| This is not OK to do globally -- even if LLVM doesn't care about the definition, maybe embedding applications or OS headers do? |$ find include -iname '*.h' | xargs grep '^#' -- | grep -vE '^.*:.*(LLVM_|cplusplus|endif|else|include|define )'| grep -vw Support | wc -l|| || ||*57*| I think it's perfectly realistic to get that number down to 0. We can start by putting a check like that in the build system, first to emit a warning, and ultimately to make violations a build error. This...

...ects rather than making the makefiles deal with them. I think in > most cases these are just historical artifacts that have been with the > projects since long before the new Makefile.rules of last fall. I agree. >> llvm/Makefile.config.in have lines: >> >> INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh >> MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs >> >> But all this projects (LLVM, Stacker, sample, llvm-java) have >> autoconf/install-sh and autoconf/mkinstalldirs in own sources. > > Which they probably shouldn't have. I'...

...VM"') do > (set > >> symbolname=%e & echo !symbolname:~1!))" > >> > >> What it does: > >> > >> For all *.lib files ina specific dir starting with LLVM call dumpbin.exe > >> (tool from Visualstudio) and write all symbols with LLVM_ into a > specific > >> file > >> > >> > >> 2017-04-05 20:40 GMT+02:00 Jakob Bornecrantz via llvm-dev > >> <llvm-dev at lists.llvm.org>: > >>> > >>> On Wed, Apr 5, 2017 at 5:20 PM, John Brawn <John.Brawn at arm.com>...

I'd like to rename all of our macros to have LLVM_ or CLANG_ as a prefix (not sure if there are any where the latter is more appropriate, but I may find them). As LLVM and Clang are more and more widely used as libraries, these generic names have a high likelihood of collision with existing macros: http://google.com/codesearch?as_q=ATTRIBUTE_UNUSE...

...ersion: 4.5.2 I successfully build the examples when running "gnumake BUILD_EXAMPLES=1" in the OBJ_DIR, however when I try to build them from outside the build tree (ie move the source into my own subtree), I run into problems. When I try to build (ocamlbuild toy.byte) after moving the llvm_* .cma, .cmo. .cmx .cmxa and .a into the local directory, I get the following error. + /usr/local/bin/ocamlc.opt llvm.cma llvm_analysis.cma llvm_executionengine.cma llvm_target.cma llvm_scalar_opts.cma -cc clang++ ast.cmo token.cmo parser.cmo codegen.cmo lexer.cmo toplevel.cmo toy.cmo bindings.o -...