similar to: [LLVMdev] [PATCH] SelectionDAG Debug

Do you have a fix for the blackfin codegen? That would be a great way to motivate this patch. Otherwise, at a glance, it appears you fixed the issues I raised, so this is fine, if it catches real bugs. Dan On Mar 1, 2010, at 10:02 AM, David Greene wrote: > Just so this doesn't get lost in threads dealing with SelectionDAG > issues, I'd like to post this patch for review. It

I need a review of this patch and if it looks sane, someone to apply it to their local sources and run tests in Debug+Checks mode. The patch replaces the intrusive SDUse list with a std::list<> when XDEBUG is active. I believe I've maintained the semantics of the SDUse list but I need a double-check. The patch exposes all kinds of problems in Debug+Checks mode. Right now most of

On Monday 01 March 2010 20:34:07 Dan Gohman wrote: > Do you have a fix for the blackfin codegen? That would be a great > way to motivate this patch. I'm not following you. Why does a fix for a bug have anything to do with a patch that catches bugs? > Otherwise, at a glance, it appears you fixed the issues I raised, > so this is fine, if it catches real bugs. Oh, it catches real

On Mar 2, 2010, at 8:58 AM, David Greene wrote: > On Monday 01 March 2010 20:34:07 Dan Gohman wrote: >> Do you have a fix for the blackfin codegen? That would be a great >> way to motivate this patch. > > I'm not following you. Why does a fix for a bug have anything to do > with a patch that catches bugs? It helps people understand what's being checked. On an

On Feb 25, 2010, at 2:24 PM, David Greene wrote: > On Thursday 25 February 2010 16:17:10 David Greene wrote: >> On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: >>> On Feb 25, 2010, at 12:01 PM, David Greene wrote: >>>> I am seeing a whole lot of failures in the tests on trunk. From >>>> discussions with Chris and others, I should not be seeing

Thanks for noticing this, Geoff. I just landed r268050 which add a cmake option for this (and unifies XDEBUG and EXPENSIVE_CHECKS). This might make it easier to setup some build bots. Thank you, Filipe On Fri, Apr 22, 2016 at 8:40 PM, Geoff Berry via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Bugs filed: > 27488 <https://llvm.org/bugs/show_bug.cgi?id=27488> librarie

On Thursday 25 February 2010 20:20:56 Dan Gohman wrote: Wrong thread? > SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) Why isn't the default constructor called? I would have expected that

Yeah, they are just triggered by lit check tests. I’ll file some bugs today, though it looks like Quentin may have already filed bugs for some of these. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday,

Hi All, Are there any bots that do any testing with clang/llvm built with XDEBUG (i.e. expensive checking)? I'm seeing 36 lit tests that currently hit asserts that are checked when XDEBUG is enabled. The checks that I'm hitting are: - DominatorTree::verifyDomTree() - DAGTypeLegalizer::PerformExpensiveChecks() - SelectionDAG checkForCyclesHelper Are these known issues or should I file

On Thursday 25 February 2010 21:27:21 David A. Greene wrote: > Thanks. I don't have the source right in front of me. I'll take a look > when I can. Here's a fixed patch. It shows the same iterator errors I'm seeing with 2.5. Run make-check with a Debug+Checks compiler. I will file a bug once I have a proper internet connection. :-/ -Dave

I just found a major bug in SelectionDAG. Well, I found it several weeks ago and finally diagnosed it today. One possible fix comes down to holding SDUses about to be processed in a queue. But this would require the SDUse copy constructor to be public. Why is it private and unimplemented right now? What's the assumption that's trying to protect?

Are SDUses ever allowed to be part of more than one list? I would think not due to the intrusive nature of the list links. However, this is what I am seeing with some testcases on trunk. I am putting together a patch that shows these kinds of problems in XDEBUG mode. I'll post it ASAP. -Dave

SDUse's Prev and Next members implement a use list. Copying them probably wouldn't immediately break anything, but it wouldn't be meaningful. Dan On Feb 24, 2010, at 3:08 PM, David Greene wrote: > I just found a major bug in SelectionDAG. Well, I found it several weeks ago > and finally diagnosed it today. > > One possible fix comes down to holding SDUses about to be

sendmail -- Version 8.14.2 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG dovecot-1.0.7 Secure and compact IMAP and POP3 servers dovecot-sieve-1.0.2 A sieve plugin for the Dovecot LDA called 'deliver' With focus on the

Even if I turn to -O0 [in other words, no optimisation passes at all], it takes the same amount of time. The time is spent in 12.94% lacsap lacsap [.] llvm::SDNode::use_iterator::operator== 7.68% lacsap lacsap [.] llvm::SDNode::use_iterator::operator* 7.53% lacsap lacsap [.] llvm::SelectionDAG::ReplaceAllUsesOfValueWith 7.28% lacsap

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

Hello, As part of enhancing atomic operations in the ARM backend, we need to extend the Ops array in AtomicSDNode. This array is a private member of AtomicSDNode, so it's only accessible within 85 lines of code, none of which have anything to do with its size. Therefore, increasing the size of Ops shouldn't at all affect the behaviour of LLVM, we supposed. Much to our surprise, this

On Wednesday 24 February 2010 18:47:19 Dan Gohman wrote: > SDUse's Prev and Next members implement a use list. Copying them > probably wouldn't immediately break anything, but it wouldn't be > meaningful. I understand that the copied SDUse wouldn't be represented in the list, so I can understand the general reasons for making the copy constructor private. In this case,

Hi, when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o -lspeex_debug -lspeexdsp -lm