public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/104353] New: ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws
@ 2022-02-02 19:30 ckk at kvr dot at
  2022-02-16 15:48 ` [Bug target/104353] " segher at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: ckk at kvr dot at @ 2022-02-02 19:30 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 104353
           Summary: ppc64le: Apparent reliance on undefined behavior of
                    xvcvdpsxws
           Product: gcc
           Version: 11.2.0
               URL: https://github.com/numpy/numpy/issues/20964#issuecomme
                    nt-1027865665
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ckk at kvr dot at
  Target Milestone: ---

Created attachment 52331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52331&action=edit
Minimal test case for reproduction

I ran into a strange numpy error on ppc64le that only occurred inside a ppc64le
QEMU instance. In short, casting arrays of i doubles 1.0 to ints 1 worked as
expected on native hardware, but produced the following bogus results when
running inside a VM:

i = 1:   1
i = 2:   1 1
i = 3:   1 1 1
i = 4:   0 0 0 0
i = 5:   0 0 0 0 1
i = 6:   0 0 0 0 1 1
i = 7:   0 0 0 0 1 1 1
i = 8:   0 0 0 0 0 0 0 0
i = 9:   0 0 0 0 0 0 0 0 1
...


Guided by the numpy folks, a SIMD issue was suspected, and I managed to create
a minimal test case (attached here) with which this could be reproduced. It
only occurs with -O3.

I then filed an issue with QEMU, where the issue was quickly rejected. This led
to further analysis by the numpy folks. There, it was discovered that GCC is
apparently relying on undefined behavior of the xvcvdpsxws instruction, which
happened to work on native hardware because it happen to exhibit that behavior.

I'm only summarizing here; there's a great analysis in detail, and a much
better test case, on the GitHub issue, which I have linked in the URL as I'd
prefer not to reproduce the author's work here.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/104353] ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws
  2022-02-02 19:30 [Bug c/104353] New: ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws ckk at kvr dot at
@ 2022-02-16 15:48 ` segher at gcc dot gnu.org
  2022-02-16 19:55 ` ckk at kvr dot at
  2022-02-18  8:43 ` seiko at imavr dot com
  2 siblings, 0 replies; 4+ messages in thread
From: segher at gcc dot gnu.org @ 2022-02-16 15:48 UTC (permalink / raw)
  To: gcc-bugs

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
This is not a bug.

Please read the second programming note for xvcvdpsxws in ISA 3.1:

  Previous versions of the architecture allowed the contents of words 1
  and 3 of the result register to be undefined. However, all processors
  that support this instruction write the result into words 0 and 1 and
  words 2 and 3 of the result register, as is required by this version
  of the architecture.

It sounds like QEMU needs fixing to behave like all hardware does?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/104353] ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws
  2022-02-02 19:30 [Bug c/104353] New: ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws ckk at kvr dot at
  2022-02-16 15:48 ` [Bug target/104353] " segher at gcc dot gnu.org
@ 2022-02-16 19:55 ` ckk at kvr dot at
  2022-02-18  8:43 ` seiko at imavr dot com
  2 siblings, 0 replies; 4+ messages in thread
From: ckk at kvr dot at @ 2022-02-16 19:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Christian Kastner <ckk at kvr dot at> ---
Thank you for resolving this.

Commenting just to link to to the QEMU issue in GitLab (which I do here, as
"See Also" doesn't seem to support GitLab).

https://gitlab.com/qemu-project/qemu/-/issues/852

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/104353] ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws
  2022-02-02 19:30 [Bug c/104353] New: ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws ckk at kvr dot at
  2022-02-16 15:48 ` [Bug target/104353] " segher at gcc dot gnu.org
  2022-02-16 19:55 ` ckk at kvr dot at
@ 2022-02-18  8:43 ` seiko at imavr dot com
  2 siblings, 0 replies; 4+ messages in thread
From: seiko at imavr dot com @ 2022-02-18  8:43 UTC (permalink / raw)
  To: gcc-bugs

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

Sayed Adel <seiko at imavr dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seiko at imavr dot com

--- Comment #3 from Sayed Adel <seiko at imavr dot com> ---
that close leads to another bug since GCC follows the previous versions of ISA
in several places. for example, VSX intrinsics vec_floate, vec_floato, etc. I
filled a bug for it, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104590

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-02-18  8:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-02 19:30 [Bug c/104353] New: ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws ckk at kvr dot at
2022-02-16 15:48 ` [Bug target/104353] " segher at gcc dot gnu.org
2022-02-16 19:55 ` ckk at kvr dot at
2022-02-18  8:43 ` seiko at imavr dot com

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).