Hello-

Here is the second patch that I mentioned when I submitted the other related
patch (which is awaiting review):
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01626.html. This second patch
is based on top of the first one and it closes out PR49973 and PR86904 by
adding the new option -fdiagnostics-column-unit=[display|byte]. This allows
to specify whether columns are output as simple byte counts (the current
behavior), or as display columns including handling multibyte characters and
tabs. The patch makes display columns the new default. Additionally, a
second new option -fdiagnostics-column-origin is added, which allows to make
the column 0-based (or N-based for any N) instead of 1-based. The default
remains at 1-based as it is now.

A number of testcases were explicitly testing for the old behavior, so I
have updated them to test for the new behavior instead, since the column
number adjusted for tabs is more natural to test for, and matches what
editors typically show (give or take 1 for the origin convention).

One other testcase (go.dg/arrayclear.go) was a bit of an oddity. It failed
after this patch, although it doesn't test for any column numbers. The
answer turned out to be, this test checks for identical error text on two
different lines. When the column units are changed to display columns, then
the column of the second error happens to match the line of the first
one. dejagnu then misinterprets the second error as if it matched the
location of the first one (it doesn't distinguish whether it checks for the
line number or the column number in the output). I added a comment to the
test explaining the situation; since adding the comment has the side effect
of making the first line number no longer match the second column number, it
also makes the test pass again.

It wasn't quite clear to me whether this change was appropriate for GCC 10
or not at this point. We discussed it a couple months ago here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02171.html. Either way, I hope
it isn't a problem that I submitted the patch for review now, whether it
will end up in 10 or 11. Please let me know what's normally expected?
Thanks!

Bootstrapped and regtested all languages on linux x86-64, results were the
same before and after:

FAIL 109 109
PASS 467378 467378
UNRESOLVED 1 1
UNSUPPORTED 11183 11183
UNTESTED 202 202
XFAIL 1756 1756
XPASS 36 36

Thanks for taking a look at it.

-Lewis