search for: module_code_funct

Hi, When I use the opt --insert-block-profiling command, there is " opt: Unknown command line argument '-insert-block-profiling'." When I use the opt -insert-edge-profiling t1.bc -o t1profile.bc, there is an error "Invalid MODULE_CODE_FUNCTION record" . Does anyone know how to solve the problem? Thanks very much! Best, Jianing

...but nothing obvious > pops out. I don't see anything wrong with FileCheck either. However looks here, that .bc file is in the *source* tree, not the obj tree: not llvm-dis < /ptmp/dag/llvm-project.official/llvm/trunk/test/Bitcode/null-type.ll.bc > /dev/null |& grep "Invalid MODULE_CODE_FUNCTION record" And I guess the .bc file is created by something during the test, multiple builds in parallel == everything breaks. Daniel, is the .bc file created by 'lit'? Best regards, --Edwin

....com> writes: > I don't see anything wrong with FileCheck either. > > However looks here, that .bc file is in the *source* tree, not the obj tree: > not llvm-dis < /ptmp/dag/llvm-project.official/llvm/trunk/test/Bitcode/null-type.ll.bc > /dev/null |& grep "Invalid MODULE_CODE_FUNCTION record" I think that's there from checkout. You can see it on the web. It seems I spoke too soon about build-level parallelization (running multiple parallel builds in parallel). 4.1.2 works fine for Debug+Asserts builds but fails horribly on Release+Asserts buils on SLES 10.1 when...

...ng Zhao, > When I use the opt --insert-block-profiling command, there is " opt: Unknown command line argument '-insert-block-profiling'." yes, it doesn't exist any more. > When I use the opt -insert-edge-profiling t1.bc -o t1profile.bc, there is an error "Invalid MODULE_CODE_FUNCTION record" . The profiling infrastructure is in bad shape and needs someone to work on it. Ciao, Duncan.

> > > I understood from his description that he reversed the destination and > source so that destination is the user code. > I assumed it was not lazy loaded, but that would explain the question then > :) > > Neil: can you clarify? If Teresa is right, why aren't you materializing > the destination module entirely? > > I don't think it has ever been tried

...d to use a lazy destination. > Having said that, I don't think isMaterializable should return > true for a declaration. > > > Looking at isMaterializable, I'm now a little confused about Neil's > case - the materializable bit is set to true only when > the MODULE_CODE_FUNCTION indicated that it was !isproto, which means > it should have a definition in that module. So I agree with you that > isMaterializable shouldn't be returning true when the symbol is only > available as a declaration. > > Neil - what case are you trying to handle here? If the...

greened at obbligato.org (David A. Greene) writes: > Often I run a few different builds in parallel, with different obj/build > directories. Is it possible that the test infrastructure writes > something to the source directories or some common temp directory? That > could confuse things when doing parallel build/test and would explain > all these failures. When I don't run

...-off-dbg]: ******************** TEST 'LLVM :: Bitcode/null-type.ll' FAILED ******************** [x86_64-off-dbg]: Script: [x86_64-off-dbg]: -- [x86_64-off-dbg]: not llvm-dis < /ptmp/dag/llvm-project.official/llvm/trunk/test/Bitcode/null-type.ll.bc > /dev/null |& grep "Invalid MODULE_CODE_FUNCTION record" [x86_64-off-dbg]: -- [x86_64-off-dbg]: Exit Code: 1 [x86_64-off-dbg]: [x86_64-off-dbg]: ********************

...199 -jason > > I don't see anything wrong with FileCheck either. > > However looks here, that .bc file is in the *source* tree, not the obj tree: > not llvm-dis < /ptmp/dag/llvm-project.official/llvm/trunk/test/Bitcode/null-type.ll.bc > /dev/null |& grep "Invalid MODULE_CODE_FUNCTION record" > > And I guess the .bc file is created by something during the test, multiple builds in parallel == everything breaks. > Daniel, is the .bc file created by 'lit'? > Best regards, > --Edwin > _______________________________________________ > LLVM Deve...

...see anything wrong with FileCheck either. > > > > However looks here, that .bc file is in the *source* tree, not the > > obj tree: not llvm-dis > > < /ptmp/dag/llvm-project.official/llvm/trunk/test/Bitcode/null-type.ll.bc > > > /dev/null |& grep "Invalid MODULE_CODE_FUNCTION record" > > I think that's there from checkout. You can see it on the web. Ah OK. > > It seems I spoke too soon about build-level parallelization (running > multiple parallel builds in parallel). 4.1.2 works fine for > Debug+Asserts builds but fails horribly on R...

...I use the opt --insert-block-profiling command, there is " opt: Unknown command line argument '-insert-block-profiling'." > > yes, it doesn't exist any more. > >> When I use the opt -insert-edge-profiling t1.bc -o t1profile.bc, there is an error "Invalid MODULE_CODE_FUNCTION record" . > > The profiling infrastructure is in bad shape and needs someone to work on it. > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs...

On Wed, 08 Dec 2010 12:09:27 -0600 greened at obbligato.org (David A. Greene) wrote: > Török Edwin <edwintorok at gmail.com> writes: > > > What are we left with then? Only 4.2 and 4.3? > > On SLES 10.1 at least. I think it is highly platform dependent. Also keep in mind that llvm-gcc uses the 4.2 unwinder, so if you are seeing EH failures maybe the EH info generated by

Török Edwin <edwintorok at gmail.com> writes: > What are we left with then? Only 4.2 and 4.3? On SLES 10.1 at least. I think it is highly platform dependent. > I only use 4.4 since a while, and it works fairly well. On what platform? > Are you sure it is not a bug in the regression tests themselves > (strict-aliasing bugs, etc.)? No, I'm not sure. > Which

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>