mbox series

[0/3] A few contrib/regression/btest-gcc.sh updates.

Message ID 20231123170645.ED4EB20427@pchp3.se.axis.com
Headers show
Series A few contrib/regression/btest-gcc.sh updates. | expand

Message

Hans-Peter Nilsson Nov. 23, 2023, 5:06 p.m. UTC 
Anyone using contrib/regression/btest-gcc.sh besides me?

It has, besides a copyright update, not seen love and attention in a
decade.  Also, the original author and maintainer hasn't been visibly
active with gcc.  I've contributed the other trivial, non-date changes
since 2009 and some others before that, and I use it regularly both in
my autotester and any per-target patch testing.

Thus, I volunteer to pick it up.  I intend to keep functional
compatibility.  Besides adding .sum file with optional presence as has
been done in the past, new functionality, as well as changes in
functionality, will be optional and default off, where reasonable
alternative use could otherwise break and/or have different results.

For example, I won't add an almost trivial LC_ALL=C to unify results
and avoid the problem with different LC_ALL and trying to pass state
between systems.  One such breaking setup is running btest-gcc.sh with
LC_ALL=C on one system and using the resulting state in a run with
LC_ALL=en_US.utf8 on the other.  This will break at the calls to
"comm" after "sort" between previous and current collections of
passing tests due to "g++" and "gcc" collating differently, a wart
I've discovered twice (and wrongly worked around once).  Changing that
would obviously break *some* setups.  This problem also doesn't need a
fix in btest-gcc.sh, it's trivially handled by changing its usage to
e.g. "env LC_ALL=C /path/to/btest-gcc.sh ...".  That's not a big deal
if you like me call btest-gcc.sh in *another* script.

With this mostly trivial patchset, leading up to optional handling of
XPASS, I'm sort-of testing the waters.  I knew about XPASS being
currently ignored, just didn't care enough about that as I also diff
the test-logs for my manual testing.  The biggest problem was then
that each run can't be done in parallel.

Hans-Peter Nilsson (3):
  contrib/regression/btest-gcc.sh: Handle multiple options.
  contrib/regression/btest-gcc.sh: Simplify option handling.
  contrib/regression/btest-gcc.sh: Optionally handle XPASS.

 contrib/regression/btest-gcc.sh | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

Comments

Jeff Law Nov. 23, 2023, 9:01 p.m. UTC | #1 
On 11/23/23 10:06, Hans-Peter Nilsson wrote:
> Anyone using contrib/regression/btest-gcc.sh besides me?
> 
> It has, besides a copyright update, not seen love and attention in a
> decade.  Also, the original author and maintainer hasn't been visibly
> active with gcc.  I've contributed the other trivial, non-date changes
> since 2009 and some others before that, and I use it regularly both in
> my autotester and any per-target patch testing.
> 
> Thus, I volunteer to pick it up.  I intend to keep functional
> compatibility.  Besides adding .sum file with optional presence as has
> been done in the past, new functionality, as well as changes in
> functionality, will be optional and default off, where reasonable
> alternative use could otherwise break and/or have different results.
> 
> For example, I won't add an almost trivial LC_ALL=C to unify results
> and avoid the problem with different LC_ALL and trying to pass state
> between systems.  One such breaking setup is running btest-gcc.sh with
> LC_ALL=C on one system and using the resulting state in a run with
> LC_ALL=en_US.utf8 on the other.  This will break at the calls to
> "comm" after "sort" between previous and current collections of
> passing tests due to "g++" and "gcc" collating differently, a wart
> I've discovered twice (and wrongly worked around once).  Changing that
> would obviously break *some* setups.  This problem also doesn't need a
> fix in btest-gcc.sh, it's trivially handled by changing its usage to
> e.g. "env LC_ALL=C /path/to/btest-gcc.sh ...".  That's not a big deal
> if you like me call btest-gcc.sh in *another* script.
> 
> With this mostly trivial patchset, leading up to optional handling of
> XPASS, I'm sort-of testing the waters.  I knew about XPASS being
> currently ignored, just didn't care enough about that as I also diff
> the test-logs for my manual testing.  The biggest problem was then
> that each run can't be done in parallel.
If you want it, it's yours :-)  Geoff Keating left GCC (and compilers in 
general) development eons ago to focus on security issues.  I haven't 
heard from or about him in probably ~10 years.

So series approved and no need to get explicit acks from here out.

jeff
Geoff Keating Nov. 23, 2023, 9:57 p.m. UTC | #2 
Yes, please take it, I don’t even remember what it does!

> On Nov 23, 2023, at 4:02 PM, Jeff Law <jeffreyalaw@gmail.com> wrote:
> 
> 
> 
>> On 11/23/23 10:06, Hans-Peter Nilsson wrote:
>> Anyone using contrib/regression/btest-gcc.sh besides me?
>> It has, besides a copyright update, not seen love and attention in a
>> decade.  Also, the original author and maintainer hasn't been visibly
>> active with gcc.  I've contributed the other trivial, non-date changes
>> since 2009 and some others before that, and I use it regularly both in
>> my autotester and any per-target patch testing.
>> Thus, I volunteer to pick it up.  I intend to keep functional
>> compatibility.  Besides adding .sum file with optional presence as has
>> been done in the past, new functionality, as well as changes in
>> functionality, will be optional and default off, where reasonable
>> alternative use could otherwise break and/or have different results.
>> For example, I won't add an almost trivial LC_ALL=C to unify results
>> and avoid the problem with different LC_ALL and trying to pass state
>> between systems.  One such breaking setup is running btest-gcc.sh with
>> LC_ALL=C on one system and using the resulting state in a run with
>> LC_ALL=en_US.utf8 on the other.  This will break at the calls to
>> "comm" after "sort" between previous and current collections of
>> passing tests due to "g++" and "gcc" collating differently, a wart
>> I've discovered twice (and wrongly worked around once).  Changing that
>> would obviously break *some* setups.  This problem also doesn't need a
>> fix in btest-gcc.sh, it's trivially handled by changing its usage to
>> e.g. "env LC_ALL=C /path/to/btest-gcc.sh ...".  That's not a big deal
>> if you like me call btest-gcc.sh in *another* script.
>> With this mostly trivial patchset, leading up to optional handling of
>> XPASS, I'm sort-of testing the waters.  I knew about XPASS being
>> currently ignored, just didn't care enough about that as I also diff
>> the test-logs for my manual testing.  The biggest problem was then
>> that each run can't be done in parallel.
> If you want it, it's yours :-)  Geoff Keating left GCC (and compilers in general) development eons ago to focus on security issues.  I haven't heard from or about him in probably ~10 years.
> 
> So series approved and no need to get explicit acks from here out.
> 
> jeff