From: NightStrike <nightstrike@gmail.com>
To: jcb62281@gmail.com
Cc: Thomas Koenig <tkoenig@netcologne.de>,
"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
gcc mailing list <gcc@gcc.gnu.org>,
dejagnu@gnu.org
Subject: Re: testsuite under wine
Date: Mon, 19 Dec 2022 06:13:01 -0500 [thread overview]
Message-ID: <CAF1jjLtQP7uJnVjiBO_95VDPhC-dkkRCDD7W90TpfMZtJCJSMw@mail.gmail.com> (raw)
In-Reply-To: <639FE88D.7090408@gmail.com>
On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem. The GNU
> >> Fortran I/O module certainly has interesting behavior here. Try setting
> >> TERM=dumb in the environment while running the testsuite. If that fixes
> >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> >> tool init file for GNU Fortran.
> >>
> >
> > Setting TERM doesn't help. Wine tries to emulate the windows console,
> > which requires outputting this stuff. It does so any time there's a
> > pty, and I believe that Deja creates a pty when running the tests.
> >
>
> That is a bug in Wine: the escapes should be suppressed entirely if the
> terminal does not support them---and the "dumb" terminal does not
> support them.
I think it's a paradigm difference. I'm just guessing here, but Wine
runs in a terminal that doesn't know about TERM. It's mimicking the
"cmd.exe" that you'd run on a native Windows system (I think... I'd
welcome corrections from those more knowledgeable). In theory, the
effect would be the same if I set up a remote target board to ssh to a
windows system and get dropped into a cmd.exe shell (I used to run
this way... it'd take about a week to run the whole testsuite. It
sucked...)
[...snip for now, I'm working on getting reasonable output back to
you, including an example of a case that fails, and how it responds to
your suggestion. Stay tuned...]
> > For now, I modified Wine to kludge out the code that
> > creates the console, and a long term solution needs to be on the Wine
> > side. I was just hoping for a less dirty hack from the Deja side.
> >
>
> I think that the long-term solution is that Wine should properly honor
> the TERM environment variable and not produce escape codes that the
> declared terminal does not support.
Agreed, just trying to get by for now.
> > Note that there are other problems, too. It seems that when Deja is
> > matching against "\n", it doesn't handle the different line endings of
> > Windows correctly in a cross environment. Is there a way that I can
> > set how to interpret \n in a target-board file? This affects fortran
> > and other language tests also.
>
> No---problems related to line endings are bugs in the testsuite. This
> caveat is documented in *Note: (dejagnu)Writing a test case. The manual
> explains: "Note that terminal settings may result in the insertion of
> additional `\r' characters, usually translating `\n' to `\r\n'."
>
> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some
> terminals historically needed them, even though the standard line ending
> *within* a POSIX system is "\n" by itself. Because a pty simply
> presents the "terminal" side of the interface to the controlling
> program, Expect can receive "\r\n" when the subprocess emits "\n"; the
> translation is performed by the kernel terminal driver and DejaGnu
> testsuites must be prepared to receive (and discard) excess carriage
> returns in the general case.
Here's one that tries to handle different line endings (most tests do
not do this):
gfortran.dg/parameter_array_dummy.f90
which uses:
! { dg-output " *1 aa(\n|\r\n|\r)" }
! { dg-output " *2 ab(\n|\r\n|\r)" }
! { dg-output " *3 aaab(\n|\r\n|\r)" }
! { dg-output " *4 abaa(\n|\r\n|\r)" }
! { dg-output " *5 ababab(\n|\r\n|\r)" }
But this results in:
FAIL: gfortran.dg/parameter_array_dummy.f90 -O0 output pattern test
Output was:
1 aa^M^M
2 ab^M^M
3 aaab^M^M
4 abaa^M^M
5 ababab^M^M
Should match:
*1 aa(
|^M
|^M) *2 ab(
|^M
|^M) *3 aaab(
|^M
|^M) *4 abaa(
|^M
|^M) *5 ababab(
|^M
|^M)
The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n.
(Other examples fail differently, for instance there's a Rust test
that outputs \r\r\n\n... but let's start with this one).
next prev parent reply other threads:[~2022-12-19 11:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAF1jjLtJW0juQR6L-VybJ8SSaqkfi=qN9FnxJVaY=oQBtkSLxA@mail.gmail.com>
[not found] ` <3f62bac2-ac1b-5c55-2488-ede2389d35d2@netcologne.de>
[not found] ` <CAF1jjLvJU2fnU0u0p9SwPre5mnhFdmv9pm_OvZGOvjQApCROqw@mail.gmail.com>
2022-12-17 10:52 ` Thomas Koenig
2022-12-17 23:24 ` NightStrike
2022-12-18 3:44 ` Jacob Bachmeyer
2022-12-18 21:13 ` NightStrike
2022-12-19 4:29 ` Jacob Bachmeyer
2022-12-19 10:43 ` Torbjorn SVENSSON
2022-12-19 11:00 ` NightStrike
2022-12-19 11:13 ` NightStrike [this message]
2022-12-20 3:51 ` Jacob Bachmeyer
[not found] ` <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com>
2022-12-22 1:01 ` NightStrike
2022-12-22 4:37 ` Jacob Bachmeyer
2022-12-23 10:36 ` NightStrike
2022-12-23 12:43 ` Eric Pouech
2022-12-24 4:00 ` Jacob Bachmeyer
2022-12-24 11:05 ` Mark Wielaard
2023-01-05 2:50 ` NightStrike
2023-01-06 3:33 ` Jacob Bachmeyer
2023-01-06 3:44 ` Jerry D
2023-01-08 7:12 ` NightStrike
2023-01-11 2:30 ` Jacob Bachmeyer
2023-01-11 9:33 ` NightStrike
2023-01-12 4:11 ` Jacob Bachmeyer
2023-01-06 3:41 ` Jerry D
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAF1jjLtQP7uJnVjiBO_95VDPhC-dkkRCDD7W90TpfMZtJCJSMw@mail.gmail.com \
--to=nightstrike@gmail.com \
--cc=dejagnu@gnu.org \
--cc=fortran@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=jcb62281@gmail.com \
--cc=tkoenig@netcologne.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).