similar to: [LLVMdev] can't build w/expensive checks

I am seeing the following on trunk for Debug+Checks builds: [x86_64-off-par]: # of unexpected failures 11 Here's an example failure: [x86_64-off-par]: FAIL: /ptmp/dag/llvm-project.official/llvm/trunk/test/CodeGen/PIC16/test_indf_name.ll [x86_64-off-par]: Failed with signal(SIGABRT) at line 1 [x86_64-off-par]: while running: llvm-as <

Hi John, > I get the error below when trying to build clang with expensive checks. > Works fine w/o these. Is this a known problem? this is a bug in libstdc++, and has been fixed here: http://gcc.gnu.org/viewcvs?view=revision&revision=147599 If you can't pick up the fix, try compiling clang without the -fno-rtti option. Ciao, Duncan.

Hello, I'm trying to use MC to assemble some code into a memory buffer. Whilst trying this, I ran into a segfault that I was able to reproduce using the llvm-mc tool (which makes me think it's not just me using the library incorrectly.) The bug looks like this (the binary is from a clean build of the 2.8 release): $ cat test/asm1.s movl %ebx, %eax $ ~/root/bin/llvm-mc --filetype=obj

Richard, I think adding the runtime undefined behavior checking and unifying the diagnostic output format is a great idea. This would probably be of interest to the LLVM Dev list as well. Anna. On Aug 10, 2012, at 7:48 PM, Richard Smith wrote: > Hi, > > There are three different (and mostly orthogonal, design-wise) areas where I would like to make improvements to Clang's

Hmmm, this used to work, at least it didn't on Aug 07 on x86_64: http://google1.osuosl.org:8011/builders/clang-x86_64-linux-check - Daniel On Fri, Aug 28, 2009 at 1:21 PM, Duncan Sands<baldrick at free.fr> wrote: > Hi John, > >> I get the error below when trying to build clang with expensive checks. >>   Works fine w/o these.  Is this a known problem? > >

Hi folks, Below is a short list of integer undefined behaviors executed by Clang when compiling the LLVM test suite. They seem pretty self explanatory, but let me know if not, if you cannot reproduce any of them, or if it would be better for me to file bugzillas on them. This is on x64 Linux, using r108984. Thanks, John --------------------------------- CLANG UNDEFINED at

Hi list, Here it is: I have compiled with no problem courier-imap-4.0.4 on this arch (x86_64). Now I want to update my install with 4.0.6. I want to do this because the server is not yet in a production state, so if a major flaw affects courier-imap in the future, I could react more quickly. And indeed I'm encountering problems with the make process (Since I initialy build courier-imap

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

On 12/21/2016 5:01 AM, Umesh Kalappa via llvm-dev wrote: > To context was , > > Basic requirement was to append extra string to the decl name and > update all his references to the updated name. , > > So we are constructing the DeclarationName instance as stated below > code snap. > and from DeclarationName instance ,we are constructing the > DeclarationNameInfo

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How can I use std::string in my winemaker project? If I do a #include <string> along with an #include <windows.h>, I get the following errors: - --- In file included from /usr/include/c++/3.3/i486-linux/bits/c++io.h:35, from /usr/include/c++/3.3/bits/fpos.h:44, from

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

I strongly suspect pointer union and pointer int pair style classes are the source of these... But perhaps I'm wrong On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > John, > > That’s a great post and really interesting data, thank you! > > On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote: > >

On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: > This RFC started a good discussion and I’d like to hear responses from its author > to all of the points that have been made so far. > >   > > FWIW, I’m also in favor of reusing as much from Clang as practical.  In fact, with> the combined repo now, it might make sense to factor out some common front end code > that

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

I get this on Ubuntu Hardy on ia32: llvm[1]: Compiling raw_ostream.cpp for Release build In file included from raw_ostream.cpp:14: /home/regehr/llvm/include/llvm/Support/raw_ostream.h:116: error: ‘llvm::raw_ostream& llvm::raw_ostream::operator<<(size_t)’ cannot be overloaded /home/regehr/llvm/include/llvm/Support/raw_ostream.h:108: error: with ‘llvm::raw_ostream&