similar to: [LLVMdev] Visibility warning

Hi Duncan, Does r55922 fix this for you? Dan On Sep 6, 2008, at 10:09 AM, Duncan Sands wrote: > Unlike those happy few who are seeing thousands of visibility > warnings, I get only one with gcc 4.3: > > lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: > ‘llvm::SDISelAsmOperandInfo’ declared with greater visibility than > the type of its field

Hi, I'm new to Clang / LLVM, and trying to build so that it will run natively on Windows. Used the CMake approach (thanks to whoever created the configs for this). Had to comment out "DbgInfoRemover.cpp" in one of the make files (didn't spend time to figure out why), following which CMake produced a nice working Visual Studio 2008 solution file. I opened this up in VS

Hello While building LLVM, the compiler (static analysis) is giving me a warning about "if (RangeUse[0] == 0 && RangeUse[0] == 0) {". Can somebody familar with the codebase look over it, maybe this should be "if (RangeUse[0] == 0 && RangeUse[1] == 0) {", otherwise sorry for the noise. Index: F:/dev/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp

Hi, I'm looking for some feedback on the changes represented in the attached patches, which I'll describe below. I'm sending this to both the LLVM and Clang list because it affects both, though the main focus here is LLVM. Basically, I've partially implemented some changes for choosing multiple alternative constraints largely on the LLVM side. The Clang change is to output the

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

On Aug 25, 2010, at 12:45 PM, John Thompson wrote: > Hi, > > I'm looking for some feedback on the changes represented in the > attached patches, which I'll describe below. > > I'm sending this to both the LLVM and Clang list because it affects > both, though the main focus here is LLVM. > Basically, I've partially implemented some changes for choosing

Hello, While I was trying to cross-compile Linux OMAP kernel with llvm, I have the following error message. CC arch/arm/kernel/traps.o cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:5388: void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): Assertion `(OpInfo.ConstraintType == TargetLowering::C_RegisterClass || OpInfo.ConstraintType ==

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Dale, Thanks for reviewing this. I have some newbie questions regarding the test-suite for you or anyone: I'm trying to run the test-suite as described in the "LLVM Testing Infrastructure Guide" on a Ubuntu x86 64 bit system. Initially I ran into problems with missing tools like yacc, which I fixed as I went along until the make at the test-suite level completed. However, I get

On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I > have the following error message. > > CC arch/arm/kernel/traps.o > cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/ > SelectionDAGBuild.cpp:5388: void > llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): >

CBE is fairly broken everywhere AFAIK, don't worry about it. Most of the JIT failures are in tests that exercise exception handling. Not sure if that is supposed to work in your environment, it works in some JITs and not others. The LLC failures are cause for concern. On Aug 30, 2010, at 10:59 AMPDT, John Thompson wrote: > Dale, > > Thanks for reviewing this. > > I have

Dale, I took a closer look at the first llc failure, initp1. Looking at the initp1.llc file in gdb, it appears that the statically constructed objects without the init_priority attribute are being constructed before those with it, though the test seems to expect the opposite. The initp1.llc.s file seems to have the .ctors table in the right order, but the _init code is reading the table in

On Jan 19, 2009, at 5:06 PM, David Greene wrote: > On Monday 19 January 2009 18:21, Dan Gohman wrote: > >>> Dan, how does the scheduler handle memory dependence? I'm working >>> on >>> something that requires memory dependence information for >>> MachineInstructions. >> >> At the moment, it knows simple things, like constant pool loads

Bug #4521 has been filed. traps.c has been also attached. Thanks, Won On Wed, Jul 8, 2009 at 1:38 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I have the > following error message. > > CC arch/arm/kernel/traps.o >

On Aug 30, 2010, at 3:11 PMPDT, John Thompson wrote: > Dale, > > I took a closer look at the first llc failure, initp1. Looking at > the initp1.llc file in gdb, it appears that the statically > constructed objects without the init_priority attribute are being > constructed before those with it, though the test seems to expect > the opposite. > > The

I'm close to confirming that I get the equivalent results from the test-suite with my changes, compared to a fresh tree, on a Linux x86 64 bit box. When that is the case, may I check in my current changes for the LLVM side? My preference is to develop the mult-alt support incrementally, rather than one big check-in, as I get nervous sitting on a lot of changes for a long time. I feel this

On Sep 1, 2010, at 11:03 AMPDT, John Thompson wrote: > I'm close to confirming that I get the equivalent results from the > test-suite with my changes, compared to a fresh tree, on a Linux x86 > 64 bit box. > > When that is the case, may I check in my current changes for the > LLVM side? In principle, yes, I'd like to rereview if it's changed. > My

Thanks for the bug report. The attached file isn't helpful for reproducing the problem. I don't have all the header files that are included, so I can't just try to run it through my version of llvm-gcc and see what happens. At a minimum, please attach the preprocessed source file along with the complete llvm-gcc command line that you used to compile it. That would

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>

Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we should wait until after that. Is this something you really want to get in 2.8? On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote: > Dale, > > Thanks. It's not changed, but I've enclosed a fresh patch against > today's trunk. > However, I'm seeing 28 unexpected failing tests in