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

Newer g++ compilers can emit: /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp: In member function 'int llvm::LLLexer::LexAt()': /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp:287: warning: suggest a space before ';' or explicit braces around empty body in 'for' statement /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp: In member

On Aug 4, 2011, at 9:03 AM, Duncan Sands wrote: >> >> lib/MC/MCParser/AsmLexer.cpp:149 >> while (CurChar != '\n'&& CurChar != '\n'&& CurChar != EOF) >> >> There are identical sub-expressions to the left and to the right of the '&&' >> operator: CurChar != '\n'&& CurChar != '\n'. The

Hi Lockal S, > ---- > > lib/Target/X86/X86ISelLowering.cpp:11689 > !DAG.isKnownNeverZero(LHS)&& !DAG.isKnownNeverZero(LHS)) > > Note that there are identical subexpressions '!DAG.isKnownNeverZero (LHS)' to > the left and to the right of the '&&' operator. > The second subexpression should probably be !DAG.isKnownNeverZero(RHS)). a patch

Hi. There are few one-line bugs Andrey Karpov have found with static analisys. He wrote a big article in russian on http://habrahabr.ru/blogs/compilers/125626/ for advertising purposes of static analyzer for Visual Studio his company developed. Most of the problems are easy to fix, so I list them in here for trunk version. Also few problems in clang code were found, I don't list them in here.

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.

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 am trying to build LLVM from source in FreeBSD 8.4. Here are the steps i carried out 1. Downloaded the source from http://llvm.org/releases/3.8.0/llvm-3.8.0.src.tar.xz 2. Extracted the source into a folder. 3. Created a build directory and inside it ran $ cmake ../llvm-3.8.0.src 4. Started the build using $cmake --build . It throws the following error

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=62 Summary: I patched the iptables-restore and liblptulog for string included "," " Product: iptables userspace Version: 1.2.7a Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2

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

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

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

Hi, Thanks for the information. Is it possible to compile LLVM 3.8 in FreeBSD 10.x and eventually use/run it on 8.4. Our production environment is running 8.4 and we cannot update it. Thanks, Sushil Pangeni On Wed, Jun 22, 2016 at 2:01 PM, Dimitry Andric <dimitry at andric.com> wrote: > You cannot build any llvm or clang releases after 3.4 on FreeBSD 8.x > natively, as it is not

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a BumpPtrAllocator. The

> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a

Hi, llvm::BumpPtrAllocatorImpl::Reset() looks like it has a bug. There is this check at the top: if (Slabs.empty()) return; But what if you don't have any normal Slabs allocated but only CustomSizedSlabs. I think this should be: if (Slabs.empty() && CustomSizedSlabs.empty()) return;

I wish to recode the following php code to ruby: function text_decrypt_symbol($s, $i) { # $s is a text-encoded string, $i is index of 2-char code. function returns number in range 0-255 return (ord(substr($s, $i, 1)) - 100)*16 + ord(substr($s, $i +1, 1)) - 100; } function text_decrypt($s) { if ($s == "") return $s; $enc = 85 ^ text_decrypt_symbol($s,

> On Mar 22, 2016, at 5:39 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at

FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. That said, I don't think we can be terribly cavalier with what we expect from standard allocator types, operator new, or malloc. And so I would expect LLVM_ATTRIBUTE_RETURNS_NOALIAS to not imply NONNULL, and while it seems reasonable to put NONNULL on *our* allocate function because of the