similar to: [LLVMdev] fix warning with newer g++ compilers

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

On Dec 15, 2007, at 2:13 AM, Duncan Sands wrote: > Hi, > >> - for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr); >> + for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) ; > > personally I like > > for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) {} > > better since it is more explicit. I think the bikeshed should be orange: for (++CurPtr; isdigit(CurPtr[0]);

Hi, > - for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr); > + for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) ; personally I like for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) {} better since it is more explicit. Ciao, Duncan.

Am 28.08.2011 20:02, schrieb geovanisouza92 at gmail.com: > Hi, Jo! > > I'm trying create a new programming language, and I want that it have > Unicode support (support for read and manipulate rightly the source-code and > string literals). > > But, in addition, my programming language supports "string interpolation" > string, and in these interpolations, tiny

2 new warnings in llvm: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning: 'IsConstant' may be used uninitialized in this function

A new warning: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:448: warning: 'IsConstant' may be used uninitialized in this function

Hi, all Recently I'm trying to use LLVM PGO and autoFDO. However I have some problems in the process. LLVM source code is updated on April 9th. Operating system is SUSE x86_64 1. Problems in instrumentation based PGO: clang -O2 -fprofile-instr-generate test.c -o a.out ./a.out (then default.profraw is generated) clang -O2 -fprofile-instr-use=default.profraw test.c -o a.out

I have a new instruction that takes 2 labels, and in SelectionDAGISel, I have it doing "CurMBB->addSuccessor()" for both machine blocks. The DAG node it creates also takes both blocks as SDOperands. When I lower to x86, the not-fallthrough block disappears. If I run llc with --fast, the blocks stay around, so it must be an optimization pass of some sort that doesn't realize my

Hello! I see the following build failure of the sources at the top of the trunk, on x86_64. make[2]: Entering directory `<llvm-root>/build/llvm/lib/AsmParser' llvm[2]: Compiling LLLexer.cpp for Release build llvm[2]: Compiling LLParser.cpp for Release build <llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const

For anyone to have any shot of answering your question, you need to provide more information. To start, please figure out which pass deleted the block, what does the machine function looks like before and after. Evan On Sep 19, 2008, at 4:14 PM, Edward Lee wrote: > I have a new instruction that takes 2 labels, and in SelectionDAGISel, > I have it doing

This patch adds a string attribute to each function which enables GC codegen and selects the metadata format to generate. In order to avoid adding a word to each Function for programs which do not use garbage collection (e.g. llvm-gcc, clang), this value is stored in an on-the- side table. — Gordon gc-5a-funattr.patch (+222 -22): docs/LangRef.html (+22 -3)

(gah, this turned into a huge digression, sorry) The implicit numbering of BB's seems to be a pretty frequent issue for people. Surprisingly, the issue boils down to simply changing the IR asm (.ll file) syntax so that it can have "unnamed BB's" in a recognizable way that fits in with how unnamed values work (the asmprinter makes an effort to print a comment with the BB number,

Posting to the list first, rather than filing a bug because I'm not sure this is still an intended configuration: With LLVM configured as: CXX=clang++ CC=clang cmake ../llvm/ \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=~/install/llvm-master/ \ -DLLVM_TARGETS_TO_BUILD=host \ -DLLVM_ENABLE_ASSERTIONS=true \ -DLLVM_ENABLE_LIBCXX=yes \ -DLLVM_ENABLE_LIBCXXABI=yes The check-all target

Hi, we are using usernames on our systems that contain a point '.', like "r.john". We found it necessary to patch the source to make the "scp" command work with those usernames. Cheers Kai --- openssh-2.2.0p1/scp.c Wed Aug 30 01:11:30 2000 +++ withpoint/scp.c Mon Dec 11 02:06:35 2000 @@ -1042,7 +1042,7 @@ c = *cp; if (c & 0200) goto bad; - if

+llvm-dev Can you give a bit of background on what you're trying to address here? After reading through the discussion and seeing that this is a best effort flag, I'm not sure that a function attribute is the best way to describe this. I'm open to being convinced it is, but I'd like to hear a bit more about the use case and get broader visibility on the proposal first.

http://bugzilla.mindrot.org/show_bug.cgi?id=377 Summary: Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros. Product: Portable OpenSSH Version: -current Platform: Sparc OS/Version: Solaris Status: NEW Severity: trivial Priority: P2 Component: Miscellaneous

On Tue, Nov 26, 2013 at 9:58 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Thanks for the lecture :) But I was not planning on changing a single > line in LLVM/Clang. I stick to the documentation until I've learned to > swim, perhaps even forever. Ah, now I see. You thought I meant "should I > modify the code to do this or that." I only meant to change

Thanks for the lecture :) But I was not planning on changing a single line in LLVM/Clang. I stick to the documentation until I've learned to swim, perhaps even forever. Ah, now I see. You thought I meant "should I modify the code to do this or that." I only meant to change the documentation. Please refer to the patch I've sent on LLVM-commits. That's about what I had

On Mon, May 7, 2018 at 5:52 AM, Brian Cain <brian.cain at gmail.com> wrote: > The simplest way to run a clang test case that I know of is to clone both > llvm and clang repos, run all the tests, then run an individual test. > > IIRC like so: > > git clone llvm ...... > cd llvm/tools > git clone clang ..... > cd ../../ > mkdir build > cd build > cmake

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could