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
bugpoint.patch (13.4 KB)
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....
bugpoint.patch (13.4 KB)
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
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