similar to: [LLVMdev] Miscompilation on MingW32

Hello, I have the following sequence of passes (using --debug-pass=Structure): ... ModulePass Manager FunctionPass Manager Preliminary module verification Dominator Tree Construction Module Verifier MyModulePass0 MyAnalysis Basic CallGraph Construction MyModulePass1 MyAnalysis MyModulePass2 Basic CallGraph Construction Call Graph SCC Pass

Hello folks, The makefile for 177.mesa says that for a small problem size, it will get 100 frames. But in the spec sources I have, the test folder only contains numbers for 10 frames: $ speccpu2000/benchspec/CFP2000/177.mesa/data $ wc -l test/input/numbers 10 test/input/numbers Generating 100 frames causes undefined behaviour because the program is doing unchecked fscanf on that

Hello folks, I have a small piece of C code written like this: typedef struct { char a; int b; int c; } foo; foo myFoo[5] = {{0}}; With llvm-gcc 2.5, I get the following IR: %struct.foo = type { i8, i32, i32 } @myFoo = global [5 x %struct.foo] zeroinitializer, align 32 With the current 2.6, I get this: %0 = type { i8, [11 x i8] }

Hi, I am trying to find someone who has a building/working pre pr4572 revision of llvm-gcc working on Cygwin and/or MinGW32. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090805/bbbfe6df/attachment.html>

Hello, Since 2.5 is near, I have been trying to build llvm and llvm-gcc for MingW, but hit several problem (using the current trunk). First issue is that unittests don't build for MingW, the attached patch should fix it. Second issue is that llvm-gcc fails for me with the following error: /c/cygwin/home/jlerouge/buildbot/llvm-test/gcc-build/./gcc/xgcc

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F

With recent work a plugin can now Annotate a VarDecl at the AST level, how can this be used in a Pass at the IR level? What classes are responsible for their manipulation? I assumed it would be part of Value, or something common like it, but I do not see any mentions of Annotation or Attribute. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Jul 30, 2008 at 11:32:18AM -0700, Bill Wendling wrote: > On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: >> ../../../llvm-gcc4.2-src/gcc/libgcc2.c:2095: error: conflicting types >> for 'VirtualProtect' >> >> c:/cygwin/home/jlerouge/buildbot/llvm/lib/../include/winbase.h:1998: >> error: previous declaration of 'VirtualProtect' was here

Hello, I would like to run a SPEC benchmark from llvm-test, with objdir != srcdir. Right now it doesn't work because the config file External/SPEC/Makefile.spec.config is not created by the configure script in the target objdir. The attached patch adds the above Makefile to the list of Makefile(s) configure has to process. I have tested it on my local tree (needs to regenerate configure).

On Wed, Aug 05, 2009 at 01:35:20PM +0100, Aaron Gray wrote: > Hi, > > I am trying to find someone who has a building/working pre pr4572 revision > of llvm-gcc working on Cygwin and/or MinGW32. > > Many thanks in advance, > > Aaron Hello, The last revision I had working on MingW is 74998. I know that 75131 and later are broken, not sure what the status was between

On Thu, Sep 22, 2011 at 02:46:05AM -0400, Mark Brown wrote: > With recent work a plugin can now Annotate a VarDecl at the AST level, how > can this be used in a Pass at the IR level? What classes are responsible for > their manipulation? I assumed it would be part of Value, or something common > like it, but I do not see any mentions of Annotation or Attribute. > > Thank you

On Dec 23, 2009, at 6:26 PM, Julien Lerouge wrote: > Hello folks, > > The makefile for 177.mesa says that for a small problem size, it will > get 100 frames. But in the spec sources I have, the test folder only > contains numbers for 10 frames: > > $ speccpu2000/benchspec/CFP2000/177.mesa/data $ wc -l test/input/ > numbers > 10 test/input/numbers > >

On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > Hello, > > The CodeExtractor contains a std::set<BasicBlock*> to keep track of > the > blocks to extract. Iterators on this set are not deterministic, and so > the functions that are generated are not (the order of the > inputs/outputs can change). > > The attached patch uses a SetVector instead. Ok to apply ?

On Feb 26, 2009, at 6:01 PM, Julien Lerouge wrote: > Hello, > > I have the following sequence of passes (using --debug- > pass=Structure): > > ... > ModulePass Manager > FunctionPass Manager > Preliminary module verification > Dominator Tree Construction > Module Verifier > MyModulePass0 > MyAnalysis > Basic CallGraph

On Feb 24, 2009, at 10:03 PM, Julien Lerouge wrote: > On Tue, Feb 24, 2009 at 06:24:17PM -0800, Julien Lerouge wrote: >> I haven't tested with objdir != srcdir. > > Ok, that was broken. Attached is a smaller diff that should work in > all > cases. This sounds really cool Julien! Two questions: 1) does it preserve the checking that the existing tcl stuff does, which

How can they processed? I cant seem to find any solid information about how they exist in IR form from a Passes perspective. I see things like @llvm.var.annotation in dumps but no relevant sounding methods to get at these. Thank you On Thu, Sep 22, 2011 at 1:20 PM, Julien Lerouge <jlerouge at apple.com> wrote: > On Thu, Sep 22, 2011 at 02:46:05AM -0400, Mark Brown wrote: > > With

Not sure if that's related, but we had two failures last night as well: MacOS/Universal build failed on rev 54197, when building the x86->ppc cross: cc1: warnings being treated as errors /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: no previous prototype for 'outermost_tinst_level' make[2]: *** [cp/pt.o] Error 1 MingW failed on rev 54208:

Hello, Julien > First issue is that unittests don't build for MingW, the attached > patch > should fix it. Looks ok for me, however, use __MINGW32__ - this is how it's in all LLVM tree nowadays. > working) and 61242 (first known non working). Are you running bootstrap build? --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > Not sure if that's related, but we had two failures last night as > well: > > MacOS/Universal build failed on rev 54197, when building the x86->ppc > cross: > > cc1: warnings being treated as errors > /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: > no > previous prototype for

Hi Julien Lerouge, > I have a small piece of C code written like this: > > typedef struct { > char a; > int b; > int c; > } foo; > %0 = type { i8, [11 x i8] } I guess it wants to initialize the alignment padding to zero. Anyway, it sure looks like a bug/inefficiency. Please open a bugreport. Ciao, Duncan.