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? -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: bugpoint.patch Type: application/octet-stream Size: 13722 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090225/26490248/attachment.obj>
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 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. 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....> -bw-------------- next part -------------- A non-text attachment was scrubbed... Name: bugpoint.patch Type: application/octet-stream Size: 13722 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090225/f875878d/attachment.obj> -------------- next part --------------> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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