On Feb 25, 2009, at 6:01 PM, Dale Johannesen wrote:> On Feb 25, 2009, at 4:59 PMPST, Bill Wendling wrote: > >> I'm running into a problem where I need to have the "gcc" that's >> executed by "bugpoint" take certain arguments that aren't applicable >> to "llc". So, I came up with this patch, that adds a new flag >> "-gcc-tool-args". It's similar to "-tool-args" but passes the command >> line arguments to gcc instead of to llc. >> >> Comments? > > I like the new flag but I'm not sure changing that test is the right > way to fix this failure. There is nothing inherent in that test > that requires it to be compiled 32-bit; it ought to work in > environments where llvm and the host compiler both target 64-bit > (and I think it does).I agree.> I think if you're going to change the test you need to add "target" > lines to the test to force it to be compiled 32-bit.Unfortunately, we don't have that mechanism available for C or C++ files.> The real problem is the llvm you're testing is out of sync with the > host compiler (for those following along at home, gcc defaults to 64- > bit codegen in the environment Bill is testing). I think a better > approach is to build llvm in such a way that it matches the host > compiler. Of course that will expose other bugs.... >>Maybe it's just a manner of having llc default to 64-bit codegen for the environment I'm working on. I think that it defaults to 32-bit right now. *checks* Yes, it does. And GCC is expecting 64-bit in that environment. Drat. -bw
On Feb 26, 2009, at 1:40 AMPST, Bill Wendling wrote:> On Feb 25, 2009, at 6:01 PM, Dale Johannesen wrote: > >> On Feb 25, 2009, at 4:59 PMPST, Bill Wendling wrote: >> >>> I'm running into a problem where I need to have the "gcc" that's >>> executed by "bugpoint" take certain arguments that aren't applicable >>> to "llc". So, I came up with this patch, that adds a new flag >>> "-gcc-tool-args". It's similar to "-tool-args" but passes the >>> command >>> line arguments to gcc instead of to llc. >>> >>> Comments? >> >> I like the new flag but I'm not sure changing that test is the right >> way to fix this failure. There is nothing inherent in that test >> that requires it to be compiled 32-bit; it ought to work in >> environments where llvm and the host compiler both target 64-bit >> (and I think it does). > > I agree. > >> I think if you're going to change the test you need to add "target" >> lines to the test to force it to be compiled 32-bit. > > Unfortunately, we don't have that mechanism available for C or C++ > files.? the failing test is BugPoint/misopt-basictest.ll>> The real problem is the llvm you're testing is out of sync with the >> host compiler (for those following along at home, gcc defaults to 64- >> bit codegen in the environment Bill is testing). I think a better >> approach is to build llvm in such a way that it matches the host >> compiler. Of course that will expose other bugs.... >>> > > Maybe it's just a manner of having llc default to 64-bit codegen for > the environment I'm working on. I think that it defaults to 32-bit > right now. *checks* Yes, it does. And GCC is expecting 64-bit in that > environment. > > Drat. > > -bw > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, Feb 26, 2009 at 9:36 AM, Dale Johannesen <dalej at apple.com> wrote:> > On Feb 26, 2009, at 1:40 AMPST, Bill Wendling wrote: > >> On Feb 25, 2009, at 6:01 PM, Dale Johannesen wrote: >> >>> On Feb 25, 2009, at 4:59 PMPST, Bill Wendling wrote: >>> >>>> I'm running into a problem where I need to have the "gcc" that's >>>> executed by "bugpoint" take certain arguments that aren't applicable >>>> to "llc". So, I came up with this patch, that adds a new flag >>>> "-gcc-tool-args". It's similar to "-tool-args" but passes the >>>> command >>>> line arguments to gcc instead of to llc. >>>> >>>> Comments? >>> >>> I like the new flag but I'm not sure changing that test is the right >>> way to fix this failure. There is nothing inherent in that test >>> that requires it to be compiled 32-bit; it ought to work in >>> environments where llvm and the host compiler both target 64-bit >>> (and I think it does). >> >> I agree. >> >>> I think if you're going to change the test you need to add "target" >>> lines to the test to force it to be compiled 32-bit. >> >> Unfortunately, we don't have that mechanism available for C or C++ >> files. > > ? the failing test is BugPoint/misopt-basictest.ll >I was unclear. Shouldn't type at 1AM. :) Anyway, yes, it's a .ll file problem. I might be able to coerce bugpoint to do the right thing. -bw