[Bug libstdc++/113230] New: 27_io/print/1.cc fails when run with qemu

[Bug libstdc++/113230] New: 27_io/print/1.cc fails when run with qemu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

            Bug ID: 113230
           Summary: 27_io/print/1.cc fails when run with qemu
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: testsuite-fail
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64-linux-gnu

```
Output was:
H3ll0, world!I walk the line
garbage in À garbage out

Should match:
H3ll0, world!I walk the line
garbage in . garbage out
```

So qemu (or something else) is is saying '\xc0' is 'À' due to that is the ASCII
Latin-1 character for that.

I am not sure if the real issue is that I don't have some env set incorrectly
either here for this test.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
But any single character should match "." in the regex. Is the output being
converted (somewhere) from Latin-1 to UTF-8 which means that "À" becomes more
than one byte, and the regex doesn't match?

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The point of the test is to write out a byte that isn't valid UTF-8, and check
that it's printed unchanged, as a single byte. If something does some kind of
iconv-like conversion on the test output and "fixes" the non-UTF-8 output, then
the test's assumption will not hold.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> The point of the test is to write out a byte that isn't valid UTF-8, and
> check that it's printed unchanged, as a single byte. If something does some
> kind of iconv-like conversion on the test output and "fixes" the non-UTF-8
> output, then the test's assumption will not hold.


Yes that is what I think is happening here. Qemu is doing the conversion from
Latin 1 to utf-8 .

I filed this to record it until I had sometime to look into it further. Maybe
there is some env setting I am supposed to set for qemu to prevent this from
happening.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
What does "run with qemu" mean exactly?

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 56988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56988&action=edit
dejagnu board that I use

And run the testsuite like:
export SIM_ARM=qemu-aarch64
export QEMU_LD_PREFIX=${SYSROOT}

make -j${CPUS} -k check RUNTESTFLAGS="--target_board=qemu_board
 SIM_ARM=${SIM_ARM} $1"

And have the target libraries installed already in the SYSROOT .

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Exactly the same for cris-elf, newlib, "sim that's colocated with gdb". 
Baseboard is cris-sim.exp from a standard dejagnu installation *and* (probably
the key): LC_ALL=C, which seems to contradict previous comments.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe that part of the test could just use { target { ! simulator } }

It's testing something that is highly dependent on the runtime context. It's
worth testing ... but only when we can control the context properly.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Although I guess Andrew's qemu setup doesn't match the simulator ET.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230

--- Comment #9 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
By the (In reply to Jonathan Wakely from comment #8)
> Although I guess Andrew's qemu setup doesn't match the simulator ET.

FWIW, by his uploaded board-info file calling 'load_generic_config "sim"' and a
look at what's in my /usr/share/dejagnu/config/sim.exp, and comparing that to
what's tested in ET simulator, I'd say it does: use and setting of
"set_board_info slow_simulator 1" is key.