https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107792
Torbjorn SVENSSON <azoff at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |azoff at gcc dot gnu.org
--- Comment #5 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> ---
I've been chasing a regression for a few days now related to
r13-4861-g8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5.
>From my understanding, the failure that I see only happens on macOS, but maybe
other environment are impacted too?
I can't say that I completely understand what is going on here, but what can
say is that I see extra '\r' in the DejaGNU logs from tests that use dg-output,
TCL provides exactly 1024 bytes (characters?) to expect and the last byte
happens to be '\r'. I know that this sounds really odd, but it appears to be
related to the "translation" feature that is native in TCL. If I hack DejaGNU
to configure the translation feature to be in CRLF-mode, the problem goes away,
but I have a feeling that this will break other tests/tools.
Keep in mind that there is a timing component in this problem, so not every
single test fails, but maybe 10% does. I'm able to reproduce the issue somewhat
reliably on both x86_64 and aarch64 macOS with a toolchain targeting
arm-none-eabi, but I don't think the target matters here.
In r13-4861-g8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5, all dg-output lines that
used to end with '(\n|\r\n|\r)*' were replaced with '(\n|\r\n|\r)', so that
means that an extra '\r' from expect/TCL causes the pattern to not match.
Looking though the tree, I see a lot more places where this *may* case problem
for macOS.
@Jonathan, what do you think is the appropriate fix for the regression on
macOS?
