This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 add code for exp, exp2, exp10/pow10
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 23 Oct 2006 22:45:59 -0600 (MDT)
- Subject: Re: [PATCH]: PR29335 add code for exp, exp2, exp10/pow10
On Tue, 24 Oct 2006, Kaveh R. GHAZI wrote:
> Would you please reconsider this request and allow me to keep this naming
> scheme or something similar?
Sure. As a compromise how about builtin-math-notdone-1.c? Or better yet
just builtin-math-2.c? This at least helps classify the set of builtins
covered by the tests. I agree that it'd be nice not to force "foo" to be
a single libm function such as "sin" or "cos" (requiring you/me to split
these tests into trivial fragments). I think using categories/classes
such as "math", "trig", "mpfr", "expN", "stringop" or "memop" is
acceptable, and has precedent. My hesitation was with the use of
Traditionally, we've tended not to use filenames to distinguish the type
of test; link_error vs. scan-tree vs. execution vs. untransformed vs ICE,
but instead by which aspect of compiler functionality is covered by
the test. Hence, a Wfoo-X.c will always test for warnings, but it's the
number X rather than the filename's "foo" that encodes/hides whether a
test checks the diagnostic is emitted or silenced.
The concept of "notdone" in a test filename is slightly strange, as
the GCC testsuite already has several thousand tests to check that
code is left untransformed, but we've never yet used "notdone" or
"unoptimized" or similar in the filename. Not that past usage is a good
guide, otherwise the new test could end up being called 20061023-1.c :->
It's nothing personal or specific to this patch, I'd be equally opposed
to a new "fold-notdone-1.c" test as well. fold-const.c is huge, and
"notdone" is perhaps not the best datum to convey in an FAIL list.
I'm a little embarrased that we sequentially got up to builtins-55.c
before we started subclassifying the tests by which libc/libm builtin
functions they covered.
Its not that I want you to split up the tests, but that the name
should be more informative.
Does this help clarify my objection? Thoughts? Perhaps Ian and/or
Janis as testsuite maintainer would like to comment on suggested
testcase naming style? My understanding is that there's currently
a trend away from using dates and PR numbers in filenames towards
much more meaningful identifiers. To date these have tended to be
based on "what" and "where" rather than "how" (or "what-not").