This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING: Re: [PATCH 05/05] Add command-line option-parsing to jit testcases


On Mon, 2014-12-08 at 13:57 -0800, Mike Stump wrote:
> On Dec 8, 2014, at 12:44 PM, David Malcolm <dmalcolm@redhat.com>
> wrote:
> > On Tue, 2014-11-25 at 20:34 -0500, David Malcolm wrote:
> >> Add command-line option-parsing to the testcases, so that we can
> >> manipulate them without needing a recompile (e.g. varying
> >> optimization levels etc).
> >> 
> >> This uses getopt_long, which is a GNU extension to libc.  Is that
> >> acceptable?
> > 
> > Ping.  Specifically, is it acceptable to use getopt_long within the
> jit
> > testcases, or should I find another way to do this (e.g. just
> getopt)?
> 
> So, the standard by which we measure, does it kill building or testing
> of ada on mingwin?  If it does, then no, not acceptable.  Iâd like to
> think there is nothing you can do in jit.exp that could do that.  So,
> from this perspective, yeah, feel free to do what you want.  Git it
> done first.  The second person that wants to port your code to a new
> machine (a different machine) will trip over all the bad things you
> did, and someone will then have to fix them.
> 
> If you only use what gcc already sues, you will be portable to
> everything gcc is portable to.  If you use GNU extensions to libc,
> well, that isnât portable enough in general.  Heck, even whatâs in
> libc isnât portable enough, thatâs half the reason why we have
> autoconf in the first place.
> 
> If jit is on by default everywhere, then you need to be portable
> everywhere.  If only on for linux, then well, it already has GNU
> extensions in libc.  I donât know if it is on by default and you
> didnât say, so, hard to comment on it.

Thanks.

The only stuff I'm using getopt_long for is to make the binaries built
by jit.exp be more flexible e.g. so that I can turn down the number of
iterations they run when running under valgrind (and potentially other
tweaks, so e.g. I can experiment with them under gdb without having to
recompile them)

Hence I think we can simply fall back to ignoring argv on hosts that
don't support getopt_long; it should merely make the testsuite less
flexible.  Not sure how best to encode such a test though - check for it
in jit.exp, or in configure, I suppose.

Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]