This is the mail archive of the
mailing list for the GCC project.
Re: Testcases that assume argc != 0
- From: Mark Mitchell <mark at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org, richard at codesourcery dot com
- Date: Mon, 18 Sep 2006 13:47:16 -0700
- Subject: Re: Testcases that assume argc != 0
- References: <email@example.com>
Richard Sandiford wrote:
Two testcases added this year assume that argc != 0. Unfortunately,
the standard specifically allows it to be zero, and MIPS libgloss
takes advantage of this.
As always there are too many options ;) We could:
(1) Skip the tests on targets where argc might be zero.
(2) Change libgloss.
(3) Pass a nonzero value in some other way that is too complicated
for the optimisers to propagate as a constant.
(4) Make the test pass if argc == 0.
(1) means building up a list of targets, which seems a lot of effort for
such a small thing.
> I don't like (2) because I think what libgloss is
doing is sensible when no executable name or command line arguments are
available. (The simulator could make them available through semihosting,
but they aren't necessarily available on real boards.)
(3) might perturb the original test too much. I suppose the same is
true of any change
to the test itself, including (4), but I thought (4) was safer and was
probably the way to go.
I think (3) would be better, especially given that there are only two
test cases to change. The reason I think it would be better is that
then the testcases will continue to test what they are intended to test
on targets without a command-line. (4) is essentially like (1), from a
validation perspective, although it is better from an engineering
perspective, since it automatically skips the test on all platforms that
As I understand it, the goal here is to get the value "1", in such a way
as the optimizers do not understand it to be a constant. So, how about
volatile int one = 1;
? This should be forever immune from optimization and seems a
relatively simple change. If that works, and if yu like that approach,
However, as I write this, I don't have the GCC sources at hand, so it
might be that I'm speaking nonsense. If so, just say so. :-)
(650) 331-3385 x713