[Bug c/63673] New: VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[Bug c/63673] New: VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[markos at freevec dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4508 bytes --]

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

            Bug ID: 63673
           Summary: VSX intrinsic vec_vsx_ld fails to compile with double,
                    maps to wrong instructions with float
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: markos at freevec dot org

Created attachment 33836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33836&action=edit
failing to compile testcase for vec_vsx_ld using doubles

These are actually two issues, but I'm filing a single bug report as it looks
like they are related.

First the build error, I've created a small failing testcase (also attached):

--
#include <altivec.h>

int main() {
        double __attribute__((aligned(16))) d[4] = {0.0, 1.0, 2.0, 3.0 };

        vector double v = vec_vsx_ld(8, d); // should load {1.0, 2.0}
}
--

This fails to compile under Debian gcc (4.9.1-19), with the following error:

$ gcc vec_vsx_ld_fail.c -c
vec_vsx_ld_fail.c: In function ‘main’:
vec_vsx_ld_fail.c:6:2: error: invalid parameter combination for AltiVec
intrinsic
  vector double v = vec_vsx_ld(4, d); // should load {1.0, 2.0}

Casting d to (float *) makes it compile, but vec_vsx_ld intrinsic definitely
should handle double parameters, so I think this is a bug.

Now the second problem, a similar testcase for float (also attached):
--
#include <altivec.h>

int main() {
        float __attribute__((aligned(16))) f[8] = {0.0, 1.0, 2.0, 3.0, 4.0,
5.0, 6.0, 7.0 };

        vector float v = vec_vsx_ld(4, f); // should load {1.0, 2.0, 3.0, 4.0}
}
--

This does compile, but the asm output uses the lxvd2x asm instruction, when
according the the ISA, lxvw4x should be used -at least according to my
understanding (page 359, Power ISA 2.07). Asm output also attached.
>From gcc-bugs-return-465193-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 29 03:30:27 2014
Return-Path: <gcc-bugs-return-465193-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29545 invoked by alias); 29 Oct 2014 03:30:26 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29509 invoked by uid 48); 29 Oct 2014 03:30:21 -0000
From: "andi-gcc at firstfloor dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63672] New: xbegin/xend/xabort missing memory barriers
Date: Wed, 29 Oct 2014 07:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: andi-gcc at firstfloor dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-63672-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg02214.txt.bz2
Content-length: 745

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc672

            Bug ID: 63672
           Summary: xbegin/xend/xabort missing memory barriers
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andi-gcc at firstfloor dot org

Created attachment 33835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3835&actioníit
proposed patch adding barriers

No test case currently, but we got a report that the builtins for x86 RTM
xbegin/xend/xabort are missing implicit memory barriers. This can cause code to
be moved outside the critical sections, breaking the program.

[Bug c/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[markos at freevec dot org]

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

--- Comment #1 from Konstantinos Margaritis <markos at freevec dot org> ---
Created attachment 33837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33837&action=edit
testcase for vec_vsx_ld using floats

[Bug c/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[markos at freevec dot org]

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

--- Comment #2 from Konstantinos Margaritis <markos at freevec dot org> ---
Created attachment 33838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33838&action=edit
asm output for testcase for vec_vsx_ld using floats

[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2014-11-20
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #4 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Well, I see that the documentation states that (double *) should be allowed.  I
find that surprising but there it is. ;)  So this should be fixed, but in the
meanwhile you can use the type cast to (vector double *).

[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |wschmidt at gcc dot gnu.org

--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Patch in progress for the missing (double *) support.

[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[markos at freevec dot org]

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

--- Comment #6 from Konstantinos Margaritis <markos at freevec dot org> ---
Hi Bill, 

Thanks for the fix in the double * patch. It's listed as a valid option in:
https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html

vector double vec_vsx_ld (int, const double *);

Similarly for vec_vsx_st:

void vec_vsx_st (vector double, int, double *);

Also, thanks for the clarifications for the lxvw4x.

[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Author: wschmidt
Date: Fri Nov 21 15:38:15 2014
New Revision: 217930

URL: https://gcc.gnu.org/viewcvs?rev=217930&root=gcc&view=rev
Log:
2014-11-21  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

    PR target/63673
    * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Allow
    the base pointer of vec_vsx_ld and vec_vsx_st to take a pointer to
    double.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-c.c

[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Author: wschmidt
Date: Fri Nov 21 15:39:20 2014
New Revision: 217931

URL: https://gcc.gnu.org/viewcvs?rev=217931&root=gcc&view=rev
Log:
2014-11-21  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

    PR target/63673
    * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Allow
    the base pointer of vec_vsx_ld and vec_vsx_st to take a pointer to
    double.


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-c.c

[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
This has also been fixed in trunk.  A typo in my log message prevented the
automatic post to this bugzilla.

All work complete.