similar to: [LLVMdev] Many tests fail on Win64

In a debug build you should get a stack trace by default, which would be helpful here. I can try to repro later today, but I'm not surprised there are issues because most people I know stick with 32-bit builds even on 64-bit Windows. On Mon, Apr 29, 2013 at 4:27 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > > > I check-out the latest version of

I fell over this issue yesterday myself with lots of asserts being thrown. I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function AssemblyWriter::printFunction(const Function *F) Looking at the code I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

See bills commit and chris's revert. Please fix. Sent from phone On Apr 29, 2013 8:41 AM, "Keith Walker" <keith.walker at arm.com> wrote: > I fell over this issue yesterday myself with lots of asserts being thrown. > > I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function > AssemblyWriter::printFunction(const Function *F) > > Looking at the code

Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes: > No tests fail with the patch below, so I would say it's pretty useless. It > seems that the C bindings are the only user but we can probably just have them > return IPSCCP instead. I don't necessarily think your conclusion is wrong, but the patch isn't proving what you think it's proving. In fact, the

I tried to compile the "bugpoint" project on Windows 7 MSVC 10 64-bit and I see the following failure: 8>W:\LLVM_org\llvm\include\llvm/ADT/Optional.h(73): error C2839: invalid return type 'llvm::GlobalValue::VisibilityTypes *' for overloaded 'operator ->' 8> W:\LLVM_org\llvm\include\llvm/ADT/Optional.h(71) : while compiling class template member

On Thu, Dec 4, 2008 at 7:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 4, 2008, at 8:58 AM, Villmow, Micah wrote: > > What optimization pass promotes 32 bit math operations to 64 bit operations > so I can disable it? I have code that works fine with optimizations turned > off but fails with it turned on because of this stage. > > > Do you have a

Which transformation passes are 'safe', meaning it does not worsens the effectiveness of a later pass or the generated code? I imagine all passes which either removes data or add attributes are included in this list, plus some simplification passes: -adce -argpromotion -constmerge -constprop -deadargelim -dse -functionattrs -globaldce -globalopt -gvn -instcombine -internalize

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

On Dec 7, 2007, at 1:43 AM, Wojciech Matyjewicz wrote: > Recently, I was looking into the bug #1227. I wanted to check if > reordering optimization passes could solve it. To start with, I > tried to > reproduce the output of llvm-g++ -O3 using the combination of llvm-g++ > -O0 and opt with the appropriate passes. However, I was unable to. I > use > SVN versions of llvm and

extract below, this has already been reported a while back but still no new patch, so this email is to serve as a reminder, if someone manually fixes it for the ports tree, I dont consider that a fix, ideally we need this fixed in the source code, as not everyone will install it from ports. Chris "clang40 -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-dns -I../../src/lib-test

John removed the assertion in his major alignment tracking patch. I manually did that on the branch in r253380. On Tue, Nov 17, 2015 at 1:10 PM, Hans Wennborg <hans at chromium.org> wrote: > On Mon, Nov 16, 2015 at 7:32 PM, Tom Stellard <tom at stellard.net> wrote: > > Hi, > > > > I have just tagged 3.7.1-rc1, so it is ready for testing. As a > > reminder,

Hi, Recently, I was looking into the bug #1227. I wanted to check if reordering optimization passes could solve it. To start with, I tried to reproduce the output of llvm-g++ -O3 using the combination of llvm-g++ -O0 and opt with the appropriate passes. However, I was unable to. I use SVN versions of llvm and llvm-gcc-4.2. First, I compile example.cpp (attached; taken from the bug #1227) with: $

I've developed a working LLVM back-end (based on LLVM 2.6) for a custom architecture with its own tool chain. This tool chain creates stand-alone programs from a single assembly. We used to use GCC, which supported producing a single machine assembly from multiple source files. I modified Clang to accept the architecture, but discovered that clang-cc (or the Clang Tool subclass inside Clang)

Greetings, I have a computer with the following setup: 1)cblfs (pure 64-bit (amd64) linux), kernel2.6.34 gcc4.4.2 2)R-2.11.1 I compiled R with BLAS and lapack using the switched ( --with-blas="- lpthread -latlas -lfptf77blas" --with-lapack="-llapack -lcblas" ). (( http://cran.r-project.org/doc/manuals/R-admin.html#Linear-algebra) ) Prior to compiling R-2.11.1 sh

On Mon, 20 Mar 2006, Michael McCracken wrote: > Hi, I'm trying to access an analysis pass from the Inliner pass, and > I'm having a lot of trouble getting that to work - I can verify that > my pass is loaded and run (it is a dynamically loaded pass that is > part of an analysisgroup), however, when I access it using > getAnalysis<> from within Inliner::runOnSCC, I am

Op 29/12/2018 om 10:25 schreef Aki Tuomi: > Hi! > > Can you give > > https://github.com/dovecot/core/compare/1004822%5E..de42b54a.patch > > a try? It's in master branch. This fix is scheduled for 2.3.5. Regards, Stephan. > On 29 December 2018 at 02:51 Chris <chrcoluk at gmail.com> wrote: > > > extract below, this has already been reported a while back

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

On 3/21/06, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 20 Mar 2006, Michael McCracken wrote: > > > Hi, I'm trying to access an analysis pass from the Inliner pass, and > > I'm having a lot of trouble getting that to work - I can verify that > > my pass is loaded and run (it is a dynamically loaded pass that is > > part of an analysisgroup),

Hi, I'm trying to access an analysis pass from the Inliner pass, and I'm having a lot of trouble getting that to work - I can verify that my pass is loaded and run (it is a dynamically loaded pass that is part of an analysisgroup), however, when I access it using getAnalysis<> from within Inliner::runOnSCC, I am instead getting the default, dummy version of my analysis, which should