[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 David Edelsohn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from David Edelsohn --- Fixed
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #14 from Thomas Koenig --- Because the version in bugzilla is set to 10.0, so I assumed it occurred there, too. Even better if it is not there.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #13 from David Edelsohn --- Committed, but why gcc-10? I don't see the testcase on that branch.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #12 from Thomas Koenig --- (In reply to David Edelsohn from comment #11) > With the patch the testcase succeeds on both powerpc-ibm-aix7.2.0.0 (big > endian) and powerpc64-linux (little endian) OK for master and gcc-10 then (unless you prefer to commit this as simple and obvious :-) Thanks!
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #11 from David Edelsohn --- With the patch the testcase succeeds on both powerpc-ibm-aix7.2.0.0 (big endian) and powerpc64-linux (little endian)
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #10 from David Edelsohn --- Created attachment 48809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48809&action=edit Updated regex for either endianness The new patch updates the regexps to accept the result for either endianness. And removes the extra quoting from the regexps.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #9 from David Edelsohn ---
This set of regexps works for me:
! { dg-final { scan-tree-dump { \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
"(d\\x00\\x
00|\\x00\\x00\\x00d)"\[1\]{lb: 1 sz: 4};} "original" } }
! { dg-final { scan-tree-dump { __builtin_memmove \(\(void \*\)
&\(\*var.str2\)
\[2\]{lb: 1 sz: 4}, \(void \*\)
&"(e\\x00\\x00\\x00f\\x00\\x00|\\x00\\x00\\x00e\
\x00\\x00\\x00f)"\[1\]{lb: 1 sz: 4}, 8\);} "original" } }
! { dg-final { scan-tree-dump { \(\*var.str2\)\[4\]{lb: 1 sz: 4} =
"(\\x00\\xf6
\\x01|\\x00\\x01\\xf6)"\[1\]{lb: 1 sz: 4};} "original" } }
! { dg-final { scan-tree-dump { \(\*var.str2\)\[5\]{lb: 1 sz: 4} =
"(\\b\\xf6\\
x01|\\x00\\x01\\xf6\\b)"\[1\]{lb: 1 sz: 4};} "original" } }
Okay?
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #8 from David Edelsohn ---
It uses . where it wants to consume a quotation mark (").
Because the BE/LE difference is flipping characters, would it negate the
purpose of the test to check for one or zero characters?
! { dg-final { scan-tree-dump { \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
.d?\\x00\\x00d?.\[1\]{lb: 1 sz: 4};} "original" } }
In other words, test for the "d" or not at one end, and "d" or not at the other
end.
And the next test would become
! { dg-final { scan-tree-dump " __builtin_memmove \(\(void \*\) &\(\*var.
str2\)\[2\]{lb: 1 sz: 4}, \(void \*\\) &.e?\\x00\\x00\\x00[ef]\\x00
\\x00f?.\[1\]{lb: 1 sz: 4}, 8\);" "original" } }
Or is a possible failure that the endian was flipped?
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 Thomas Koenig changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #7 from Thomas Koenig --- *** Bug 95919 has been marked as a duplicate of this bug. ***
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #6 from Thomas Koenig --- Created attachment 48795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48795&action=edit Dump file on big-endian system If anybody wants to do the magic for the patterns on big-endian systems, here is the dump file to do it with.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #5 from Thomas Koenig --- Created attachment 48794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48794&action=edit patch for the test case, skipping the test on big-endian targets This implements Segher's suggestion to skip the test on big-endian.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #4 from Segher Boessenkool ---
Or even just { target le } yes. You can put that as the selector on just
the scan tests, and even do a separate BE version as well.
You can quote regexps with {} instead of "", that makes them much more
readable. The regexps seem to use . where they mean a literal dot, too?
Won't matter too much of course.
! { dg-final { scan-tree-dump " \\(\\*var\\.str2\\)\\\[1\\\]{lb: 1 sz: 4} =
.dx00x00.\\\[1\\\]{lb: 1 sz: 4};" "original" } }
can become
! { dg-final { scan-tree-dump { \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
.d\\x00\\x00.\[1\]{lb: 1 sz: 4};} "original" { target le } } }
and whatever BE needs.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #3 from David Edelsohn ---
{ target { le } }
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #2 from Thomas Koenig --- The problem is in the scans; the code runs fine. Does anybody have the dejagnu-fu to run the scans only on little-endian systems?
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-26 --- Comment #1 from David Edelsohn --- Confirmed.
