* [PATCH] avoid printing range table header alone
@ 2021-08-25 17:25 Martin Sebor
2021-08-25 17:46 ` Andrew MacLeod
0 siblings, 1 reply; 6+ messages in thread
From: Martin Sebor @ 2021-08-25 17:25 UTC (permalink / raw)
To: Aldy Hernandez, Andrew MacLeod, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
I noticed that the output of -fdump-tree-walloca (and probably all
passes that call gimple_ranger::export_global_ranges()) includes
the following two lines for all functions, even when there's
nothing else of relevance after them:
Exported global range table
===========================
I was a bit puzzled by it at first, wondering if it was leftover
debugging output, until I checked the code and realized it's
a header that may be (but isn't always) followed by the contents
of the table.
To reduce clutter in the dump the attached patch changes the function
to print the header only when it is followed by at least one line of
output. (Another tweak to reduce even further the amount of output
printed by default that might be worth considering is to print
the table only when TDF_DETAILS is set.)
Martin
[-- Attachment #2: gcc-dump-range.diff --]
[-- Type: text/x-patch, Size: 1959 bytes --]
Avoid printing range table header alone.
gcc/ChangeLog:
* gimple-range.cc (gimple_ranger::export_global_ranges):
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index ef3afeacc90..521d7cee5f0 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -259,16 +259,9 @@ gimple_ranger::range_of_stmt (irange &r, gimple *s, tree name)
void
gimple_ranger::export_global_ranges ()
{
- unsigned x;
- int_range_max r;
- if (dump_file)
- {
- fprintf (dump_file, "Exported global range table\n");
- fprintf (dump_file, "===========================\n");
- }
-
- for ( x = 1; x < num_ssa_names; x++)
+ for (unsigned x = 1; x < num_ssa_names; x++)
{
+ int_range_max r;
tree name = ssa_name (x);
if (name && !SSA_NAME_IN_FREE_LIST (name)
&& gimple_range_ssa_p (name)
@@ -276,21 +269,28 @@ gimple_ranger::export_global_ranges ()
&& !r.varying_p())
{
bool updated = update_global_range (r, name);
+ if (!updated || !dump_file)
+ continue;
- if (updated && dump_file)
+ if (x == 1)
{
- value_range vr = r;
- print_generic_expr (dump_file, name , TDF_SLIM);
- fprintf (dump_file, " --> ");
- vr.dump (dump_file);
+ /* Print the header only when there's something else
+ to print below. */
+ fprintf (dump_file, "Exported global range table\n");
+ fprintf (dump_file, "===========================\n");
+ }
+
+ value_range vr = r;
+ print_generic_expr (dump_file, name , TDF_SLIM);
+ fprintf (dump_file, " --> ");
+ vr.dump (dump_file);
+ fprintf (dump_file, "\n");
+ int_range_max same = vr;
+ if (same != r)
+ {
+ fprintf (dump_file, " irange : ");
+ r.dump (dump_file);
fprintf (dump_file, "\n");
- int_range_max same = vr;
- if (same != r)
- {
- fprintf (dump_file, " irange : ");
- r.dump (dump_file);
- fprintf (dump_file, "\n");
- }
}
}
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] avoid printing range table header alone
2021-08-25 17:25 [PATCH] avoid printing range table header alone Martin Sebor
@ 2021-08-25 17:46 ` Andrew MacLeod
2021-08-25 19:15 ` Martin Sebor
0 siblings, 1 reply; 6+ messages in thread
From: Andrew MacLeod @ 2021-08-25 17:46 UTC (permalink / raw)
To: Martin Sebor, Aldy Hernandez, gcc-patches
On 8/25/21 1:25 PM, Martin Sebor wrote:
> I noticed that the output of -fdump-tree-walloca (and probably all
> passes that call gimple_ranger::export_global_ranges()) includes
> the following two lines for all functions, even when there's
> nothing else of relevance after them:
>
> Exported global range table
> ===========================
>
> I was a bit puzzled by it at first, wondering if it was leftover
> debugging output, until I checked the code and realized it's
> a header that may be (but isn't always) followed by the contents
> of the table.
>
> To reduce clutter in the dump the attached patch changes the function
> to print the header only when it is followed by at least one line of
> output. (Another tweak to reduce even further the amount of output
> printed by default that might be worth considering is to print
> the table only when TDF_DETAILS is set.)
>
> Martin
Except checking x == 1 won't work if ssa_name(1) was not updated.
Just set a flag if the header hasn't been printed yet. tried and true. I
guess you can protect it behind details if you want.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] avoid printing range table header alone
2021-08-25 17:46 ` Andrew MacLeod
@ 2021-08-25 19:15 ` Martin Sebor
2021-08-25 19:34 ` Andrew MacLeod
0 siblings, 1 reply; 6+ messages in thread
From: Martin Sebor @ 2021-08-25 19:15 UTC (permalink / raw)
To: Andrew MacLeod, Aldy Hernandez, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
On 8/25/21 11:46 AM, Andrew MacLeod wrote:
> On 8/25/21 1:25 PM, Martin Sebor wrote:
>> I noticed that the output of -fdump-tree-walloca (and probably all
>> passes that call gimple_ranger::export_global_ranges()) includes
>> the following two lines for all functions, even when there's
>> nothing else of relevance after them:
>>
>> Exported global range table
>> ===========================
>>
>> I was a bit puzzled by it at first, wondering if it was leftover
>> debugging output, until I checked the code and realized it's
>> a header that may be (but isn't always) followed by the contents
>> of the table.
>>
>> To reduce clutter in the dump the attached patch changes the function
>> to print the header only when it is followed by at least one line of
>> output. (Another tweak to reduce even further the amount of output
>> printed by default that might be worth considering is to print
>> the table only when TDF_DETAILS is set.)
>>
>> Martin
>
> Except checking x == 1 won't work if ssa_name(1) was not updated.
>
> Just set a flag if the header hasn't been printed yet. tried and true. I
> guess you can protect it behind details if you want.
Doh! I've fixed that. While testing I came across another instance
of the same pattern so I've made the same change there as well. I
also took the liberty to make the output slightly more consistent
between the two dumps.
Attached is what I'm planning to commit. Please let me know if you
have any other suggestions.
FWIW, I see duplicate output in the EVRP1 dump that looks just like
it could be the output under Non-varying global ranges. I wonder if
it's the result of the block in ranger_cache::fill_block_cache guarded
by if (DEBUG_RANGE_CACHE).
Martin
[-- Attachment #2: gcc-dump-range.diff --]
[-- Type: text/x-patch, Size: 3694 bytes --]
Avoid printing range table header alone.
gcc/ChangeLog:
* gimple-range-cache.cc (ssa_global_cache::dump): Avoid printing
range table header alone.
* gimple-range.cc (gimple_ranger::export_global_ranges): Same.
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index 4138d0556c6..facf981c15d 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -628,20 +628,32 @@ ssa_global_cache::clear ()
void
ssa_global_cache::dump (FILE *f)
{
- unsigned x;
- int_range_max r;
- fprintf (f, "Non-varying global ranges:\n");
- fprintf (f, "=========================:\n");
- for ( x = 1; x < num_ssa_names; x++)
- if (gimple_range_ssa_p (ssa_name (x)) &&
- get_global_range (r, ssa_name (x)) && !r.varying_p ())
- {
- print_generic_expr (f, ssa_name (x), TDF_NONE);
- fprintf (f, " : ");
- r.dump (f);
- fprintf (f, "\n");
- }
- fputc ('\n', f);
+ /* Cleared after the table header has been printed. */
+ bool print_header = true;
+ for (unsigned x = 1; x < num_ssa_names; x++)
+ {
+ int_range_max r;
+ if (gimple_range_ssa_p (ssa_name (x)) &&
+ get_global_range (r, ssa_name (x)) && !r.varying_p ())
+ {
+ if (print_header)
+ {
+ /* Print the header only when there's something else
+ to print below. */
+ fprintf (f, "Non-varying global ranges:\n");
+ fprintf (f, "==========================\n");
+ print_header = false;
+ }
+
+ print_generic_expr (f, ssa_name (x), TDF_NONE);
+ fprintf (f, " : ");
+ r.dump (f);
+ fprintf (f, "\n");
+ }
+ }
+
+ if (!print_header)
+ fputc ('\n', f);
}
// --------------------------------------------------------------------------
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index ef3afeacc90..fb23d567971 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -259,16 +259,11 @@ gimple_ranger::range_of_stmt (irange &r, gimple *s, tree name)
void
gimple_ranger::export_global_ranges ()
{
- unsigned x;
- int_range_max r;
- if (dump_file)
- {
- fprintf (dump_file, "Exported global range table\n");
- fprintf (dump_file, "===========================\n");
- }
-
- for ( x = 1; x < num_ssa_names; x++)
+ /* Cleared after the table header has been printed. */
+ bool print_header = true;
+ for (unsigned x = 1; x < num_ssa_names; x++)
{
+ int_range_max r;
tree name = ssa_name (x);
if (name && !SSA_NAME_IN_FREE_LIST (name)
&& gimple_range_ssa_p (name)
@@ -276,21 +271,29 @@ gimple_ranger::export_global_ranges ()
&& !r.varying_p())
{
bool updated = update_global_range (r, name);
+ if (!updated || !dump_file || !(dump_flags & TDF_DETAILS))
+ continue;
- if (updated && dump_file)
+ if (print_header)
{
- value_range vr = r;
- print_generic_expr (dump_file, name , TDF_SLIM);
- fprintf (dump_file, " --> ");
- vr.dump (dump_file);
+ /* Print the header only when there's something else
+ to print below. */
+ fprintf (dump_file, "Exported global range table:\n");
+ fprintf (dump_file, "============================\n");
+ print_header = false;
+ }
+
+ value_range vr = r;
+ print_generic_expr (dump_file, name , TDF_SLIM);
+ fprintf (dump_file, " : ");
+ vr.dump (dump_file);
+ fprintf (dump_file, "\n");
+ int_range_max same = vr;
+ if (same != r)
+ {
+ fprintf (dump_file, " irange : ");
+ r.dump (dump_file);
fprintf (dump_file, "\n");
- int_range_max same = vr;
- if (same != r)
- {
- fprintf (dump_file, " irange : ");
- r.dump (dump_file);
- fprintf (dump_file, "\n");
- }
}
}
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] avoid printing range table header alone
2021-08-25 19:15 ` Martin Sebor
@ 2021-08-25 19:34 ` Andrew MacLeod
2021-08-25 23:49 ` Martin Sebor
0 siblings, 1 reply; 6+ messages in thread
From: Andrew MacLeod @ 2021-08-25 19:34 UTC (permalink / raw)
To: Martin Sebor, Aldy Hernandez, gcc-patches
On 8/25/21 3:15 PM, Martin Sebor wrote:
> On 8/25/21 11:46 AM, Andrew MacLeod wrote:
>> On 8/25/21 1:25 PM, Martin Sebor wrote:
>>> I noticed that the output of -fdump-tree-walloca (and probably all
>>> passes that call gimple_ranger::export_global_ranges()) includes
>>> the following two lines for all functions, even when there's
>>> nothing else of relevance after them:
>>>
>>> Exported global range table
>>> ===========================
>>>
>>> I was a bit puzzled by it at first, wondering if it was leftover
>>> debugging output, until I checked the code and realized it's
>>> a header that may be (but isn't always) followed by the contents
>>> of the table.
>>>
>>> To reduce clutter in the dump the attached patch changes the function
>>> to print the header only when it is followed by at least one line of
>>> output. (Another tweak to reduce even further the amount of output
>>> printed by default that might be worth considering is to print
>>> the table only when TDF_DETAILS is set.)
>>>
>>> Martin
>>
>> Except checking x == 1 won't work if ssa_name(1) was not updated.
>>
>> Just set a flag if the header hasn't been printed yet. tried and
>> true. I guess you can protect it behind details if you want.
>
> Doh! I've fixed that. While testing I came across another instance
> of the same pattern so I've made the same change there as well. I
> also took the liberty to make the output slightly more consistent
> between the two dumps.
>
> Attached is what I'm planning to commit. Please let me know if you
> have any other suggestions.
>
OK, thats fine.
> FWIW, I see duplicate output in the EVRP1 dump that looks just like
> it could be the output under Non-varying global ranges. I wonder if
> it's the result of the block in ranger_cache::fill_block_cache guarded
> by if (DEBUG_RANGE_CACHE).
>
> Martin
The cache debug mechanism hasnt been fully reworked yet... i moved GORI
and the ranger to the trace class.. I haven't decided yet what I want to
change in the cache. its a bit dated.
regardless, if your sources are up to date, DEBUG_RANGE_CACHE is now
guarded by:
#define DEBUG_RANGE_CACHE (dump_file && (param_evrp_mode &
EVRP_MODE_CACHE) \
== EVRP_MODE_CACHE)
so you'd only see that output if you specify --param=evrp-mode=cache or
debug
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] avoid printing range table header alone
2021-08-25 19:34 ` Andrew MacLeod
@ 2021-08-25 23:49 ` Martin Sebor
2021-08-26 12:55 ` Andrew MacLeod
0 siblings, 1 reply; 6+ messages in thread
From: Martin Sebor @ 2021-08-25 23:49 UTC (permalink / raw)
To: Andrew MacLeod, Aldy Hernandez, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]
On 8/25/21 1:34 PM, Andrew MacLeod wrote:
> On 8/25/21 3:15 PM, Martin Sebor wrote:
>> On 8/25/21 11:46 AM, Andrew MacLeod wrote:
>>> On 8/25/21 1:25 PM, Martin Sebor wrote:
>>>> I noticed that the output of -fdump-tree-walloca (and probably all
>>>> passes that call gimple_ranger::export_global_ranges()) includes
>>>> the following two lines for all functions, even when there's
>>>> nothing else of relevance after them:
>>>>
>>>> Exported global range table
>>>> ===========================
>>>>
>>>> I was a bit puzzled by it at first, wondering if it was leftover
>>>> debugging output, until I checked the code and realized it's
>>>> a header that may be (but isn't always) followed by the contents
>>>> of the table.
>>>>
>>>> To reduce clutter in the dump the attached patch changes the function
>>>> to print the header only when it is followed by at least one line of
>>>> output. (Another tweak to reduce even further the amount of output
>>>> printed by default that might be worth considering is to print
>>>> the table only when TDF_DETAILS is set.)
>>>>
>>>> Martin
>>>
>>> Except checking x == 1 won't work if ssa_name(1) was not updated.
>>>
>>> Just set a flag if the header hasn't been printed yet. tried and
>>> true. I guess you can protect it behind details if you want.
>>
>> Doh! I've fixed that. While testing I came across another instance
>> of the same pattern so I've made the same change there as well. I
>> also took the liberty to make the output slightly more consistent
>> between the two dumps.
>>
>> Attached is what I'm planning to commit. Please let me know if you
>> have any other suggestions.
>>
> OK, thats fine.
I got ahead of myself and pushed the change in r12-3144 before my
second test run finished. A few tree-ssa tests needed adjusting
after the TDF_DETAILS change. I fixed those r12-3152.
>
>
>> FWIW, I see duplicate output in the EVRP1 dump that looks just like
>> it could be the output under Non-varying global ranges. I wonder if
>> it's the result of the block in ranger_cache::fill_block_cache guarded
>> by if (DEBUG_RANGE_CACHE).
>>
>> Martin
>
>
> The cache debug mechanism hasnt been fully reworked yet... i moved GORI
> and the ranger to the trace class.. I haven't decided yet what I want to
> change in the cache. its a bit dated.
>
> regardless, if your sources are up to date, DEBUG_RANGE_CACHE is now
> guarded by:
>
> #define DEBUG_RANGE_CACHE (dump_file && (param_evrp_mode &
> EVRP_MODE_CACHE) \
> == EVRP_MODE_CACHE)
>
> so you'd only see that output if you specify --param=evrp-mode=cache or
> debug
It's not a big deal but the output I noticed is actually coming
from gimple_ranger::dump_bb (). In the test I happened to look
at it shows up just before Non-varying global ranges: It's
attached just to show you what I mean.
Martin
[-- Attachment #2: 20011015-1.c.038t.evrp --]
[-- Type: text/plain, Size: 4616 bytes --]
;; Function foo (foo, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Substituting values and folding statements
Folding statement: _3 = *x_2(D);
Not folded
Folding statement: return _3;
Not folded
=========== BB 2 ============
<bb 2> :
_3 = *x_2(D);
return _3;
char foo (char * x)
{
char _3;
<bb 2> :
_3 = *x_2(D);
return _3;
}
;; Function bar (bar, funcdef_no=1, decl_uid=1946, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Substituting values and folding statements
Folding statement: saved_stack.1_16 = __builtin_stack_save ();
Not folded
Folding statement: _18 = *x_17(D);
Not folded
Folding statement: _1 = (long int) _18;
Not folded
Folding statement: _2 = _1 + -1;
Registering value_relation (_2 < _1) (bb2) at _2 = _1 + -1;
Not folded
Folding statement: _3 = (sizetype) _2;
Not folded
Folding statement: _4 = (sizetype) _18;
Not folded
Folding statement: _5 = (bitsizetype) _4;
Not folded
Folding statement: _6 = _5 * 64;
Not folded
Folding statement: _8 = _4 * 8;
Not folded
Folding statement: arr.0_26 = __builtin_alloca_with_align (_8, 64);
Not folded
Folding statement: __builtin_stack_restore (saved_stack.1_16);
Not folded
Folding statement: return;
Not folded
=========== BB 2 ============
Relational : (_2 < _1)
<bb 2> :
saved_stack.1_16 = __builtin_stack_save ();
_18 = *x_17(D);
_1 = (long int) _18;
_2 = _1 + -1;
_3 = (sizetype) _2;
_4 = (sizetype) _18;
_5 = (bitsizetype) _4;
_6 = _5 * 64;
_8 = _4 * 8;
arr.0_26 = __builtin_alloca_with_align (_8, 64);
__builtin_stack_restore (saved_stack.1_16);
return;
_1 : long int [-128, 127]
_2 : long int [-129, 126]
_3 : sizetype [0, 126][18446744073709551487, +INF]
_4 : sizetype [0, 127][18446744073709551488, +INF]
_5 : bitsizetype [0, 127][18446744073709551488, 18446744073709551615]
_6 : bitsizetype [0, 8128][0x3fffffffffffffe000, 0x3fffffffffffffffc0]
_8 : sizetype [0, 1016][18446744073709550592, 18446744073709551608]
arr.0_26 : void *[0:D.1956] * [1B, +INF]
Non-varying global ranges:
=========================:
_1 : long int [-128, 127]
_2 : long int [-129, 126]
_3 : sizetype [0, 126][18446744073709551487, +INF]
_4 : sizetype [0, 127][18446744073709551488, +INF]
_5 : bitsizetype [0, 127][18446744073709551488, 18446744073709551615]
_6 : bitsizetype [0, 8128][0x3fffffffffffffe000, 0x3fffffffffffffffc0]
_8 : sizetype [0, 1016][18446744073709550592, 18446744073709551608]
arr.0_26 : void *[0:D.1956] * [1B, +INF]
Exported global range table:
============================
_1 : long int [-128, 127]
_2 : long int [-129, 126]
_3 : sizetype ~[127, 18446744073709551486]
_4 : sizetype ~[128, 18446744073709551487]
_5 : bitsizetype [0, 18446744073709551615]
irange : bitsizetype [0, 127][18446744073709551488, 18446744073709551615]
_6 : bitsizetype [0, 0x3fffffffffffffffc0]
irange : bitsizetype [0, 8128][0x3fffffffffffffe000, 0x3fffffffffffffffc0]
_8 : sizetype [0, 18446744073709551608]
irange : sizetype [0, 1016][18446744073709550592, 18446744073709551608]
arr.0_26 : void *[0:D.1956] * [1B, +INF]
void bar (char * x)
{
char D.1968;
void *[0:D.1956] * arr.0;
sizetype D.1956;
long int _1;
long int _2;
sizetype _3;
sizetype _4;
bitsizetype _5;
bitsizetype _6;
sizetype _8;
void * saved_stack.1_16;
char _18;
<bb 2> :
saved_stack.1_16 = __builtin_stack_save ();
_18 = *x_17(D);
_1 = (long int) _18;
_2 = _1 + -1;
_3 = (sizetype) _2;
_4 = (sizetype) _18;
_5 = (bitsizetype) _4;
_6 = _5 * 64;
_8 = _4 * 8;
arr.0_26 = __builtin_alloca_with_align (_8, 64);
__builtin_stack_restore (saved_stack.1_16);
return;
}
;; Function baz (baz, funcdef_no=2, decl_uid=1950, cgraph_uid=3, symbol_order=2)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Substituting values and folding statements
Folding statement: saved_stack.1_3 = __builtin_stack_save ();
Not folded
Folding statement: __builtin_stack_restore (saved_stack.1_3);
Not folded
Folding statement: return;
Not folded
=========== BB 2 ============
<bb 2> :
saved_stack.1_3 = __builtin_stack_save ();
__builtin_stack_restore (saved_stack.1_3);
return;
void baz (char * x)
{
void * saved_stack.1_3;
<bb 2> :
saved_stack.1_3 = __builtin_stack_save ();
__builtin_stack_restore (saved_stack.1_3);
return;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] avoid printing range table header alone
2021-08-25 23:49 ` Martin Sebor
@ 2021-08-26 12:55 ` Andrew MacLeod
0 siblings, 0 replies; 6+ messages in thread
From: Andrew MacLeod @ 2021-08-26 12:55 UTC (permalink / raw)
To: Martin Sebor, Aldy Hernandez, gcc-patches
On 8/25/21 7:49 PM, Martin Sebor wrote:
> On 8/25/21 1:34 PM, Andrew MacLeod wrote:
>
>
>>
>>
>>> FWIW, I see duplicate output in the EVRP1 dump that looks just like
>>> it could be the output under Non-varying global ranges. I wonder if
>>> it's the result of the block in ranger_cache::fill_block_cache guarded
>>> by if (DEBUG_RANGE_CACHE).
>>>
>>> Martin
>>
>>
>> The cache debug mechanism hasnt been fully reworked yet... i moved
>> GORI and the ranger to the trace class.. I haven't decided yet what I
>> want to change in the cache. its a bit dated.
>>
>> regardless, if your sources are up to date, DEBUG_RANGE_CACHE is now
>> guarded by:
>>
>> #define DEBUG_RANGE_CACHE (dump_file && (param_evrp_mode &
>> EVRP_MODE_CACHE) \
>> == EVRP_MODE_CACHE)
>>
>> so you'd only see that output if you specify --param=evrp-mode=cache
>> or debug
>
> It's not a big deal but the output I noticed is actually coming
> from gimple_ranger::dump_bb (). In the test I happened to look
> at it shows up just before Non-varying global ranges: It's
> attached just to show you what I mean.
>
> Martin
If you ask for details, you get a ranger IL dump with ranges after the
pass... Its difficult to show any contextual range calculations otherwise.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-08-26 12:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-25 17:25 [PATCH] avoid printing range table header alone Martin Sebor
2021-08-25 17:46 ` Andrew MacLeod
2021-08-25 19:15 ` Martin Sebor
2021-08-25 19:34 ` Andrew MacLeod
2021-08-25 23:49 ` Martin Sebor
2021-08-26 12:55 ` Andrew MacLeod
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).