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

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

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

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/.

? Fri, 9 May 2025 11:09:22 +1000 Stephen Wade <stephematician at gmail.com> ?????: > inlined from ?std::vector<double> literanger::adjust_pvalues(const > std::vector<double>&)? at ../src/literanger/utility_math.h:99:48: > /usr/include/c++/13/bits/stl_algobase.h:437:30: warning: ?void* > __builtin_memmove(void*, const void*, long unsigned int)? writing >

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.

The literanger package is no longer passing on CRAN (https://CRAN.R-project.org/package=literanger) due to array-bound warnings in GCC 13.3 and 14.2 (more details below). This _looks_ to me like one of either a) a compiler bug, b) a false positive, or c) (very unlikely) something in the standard library implementation. Have others seen warnings like this recently, and if so, what have you done

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,

-----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

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: