[Bug c++/56025] New: ARM NEON polynomial types have broken overload resolution

[Bug c++/56025] New: ARM NEON polynomial types have broken overload resolution

[Tim.Northover at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56025

             Bug #: 56025
           Summary: ARM NEON polynomial types have broken overload
                    resolution
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Tim.Northover@arm.com


While investigating bug #56024, we discovered this problem in the same area.
Essentially, GCC has semi-special builtin types to cover poly8_t and poly16_t
defined in arm_neon.h.

These types are used by G++ when calculating the overload resolution. The
following two functions can both be defined with no issues in the front-end:

#include <arm_neon.h>
void foo(short s) {}
void foo(__builtin_neon_poly16 s) {}

However, in the resulting assembly they are both mangled as _Z3foos, which
causes a conflict.

This mangling area is likely to be affected by any change fixing 56024, so a
sensible combined solution might be a good idea.

[Bug c++/56025] ARM NEON polynomial types have broken overload resolution

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56025

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm-eabi, arm-linux-gnueabi
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-18
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> 2013-01-18 09:51:40 UTC ---
Agreed.  If there's a conflict in the mangling, it really should be detectable
at definition time if the two definitions appear in the same translation unit.

[Bug target/56025] ARM NEON polynomial types have broken overload resolution

[belagod at gcc dot gnu.org]

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

Tejas Belagod <belagod at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |belagod at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #2 from Tejas Belagod <belagod at gcc dot gnu.org> ---
(In reply to Tim Northover from comment #0)
> While investigating bug #56024, we discovered this problem in the same area.
> Essentially, GCC has semi-special builtin types to cover poly8_t and
> poly16_t defined in arm_neon.h.
> 
> These types are used by G++ when calculating the overload resolution. The
> following two functions can both be defined with no issues in the front-end:
> 
> #include <arm_neon.h>
> void foo(short s) {}
> void foo(__builtin_neon_poly16 s) {}
> 
> However, in the resulting assembly they are both mangled as _Z3foos, which
> causes a conflict.
> 
> This mangling area is likely to be affected by any change fixing 56024, so a
> sensible combined solution might be a good idea.

This should now be fixed. Now mangled as _Z3foos and _Z3foo10__Poly16_t
respectively.

    .cpu generic+fp+simd
    .file    "gpp.cpp"
    .text
    .align    2
    .p2align 3,,7
    .global    _Z3foos
    .type    _Z3foos, %function
_Z3foos:
.LFB3026:
    .cfi_startproc
    ret
    .cfi_endproc
.LFE3026:
    .size    _Z3foos, .-_Z3foos
    .align    2
    .p2align 3,,7
    .global    _Z3foo10__Poly16_t
    .type    _Z3foo10__Poly16_t, %function
_Z3foo10__Poly16_t:
.LFB3027:
    .cfi_startproc
    ret
    .cfi_endproc
.LFE3027:
    .size    _Z3foo10__Poly16_t, .-_Z3foo10__Poly16_t
    .ident    "GCC: (unknown) 5.0.0 20141229 (experimental)"

[Bug target/56025] ARM NEON polynomial types have broken overload resolution

[belagod at gcc dot gnu.org]

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

Tejas Belagod <belagod at gcc dot gnu.org> changed:

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

--- Comment #3 from Tejas Belagod <belagod at gcc dot gnu.org> ---
(In reply to Tejas Belagod from comment #2)
> (In reply to Tim Northover from comment #0)
> > While investigating bug #56024, we discovered this problem in the same area.
> > Essentially, GCC has semi-special builtin types to cover poly8_t and
> > poly16_t defined in arm_neon.h.
> > 
> > These types are used by G++ when calculating the overload resolution. The
> > following two functions can both be defined with no issues in the front-end:
> > 
> > #include <arm_neon.h>
> > void foo(short s) {}
> > void foo(__builtin_neon_poly16 s) {}
> > 
> > However, in the resulting assembly they are both mangled as _Z3foos, which
> > causes a conflict.
> > 
> > This mangling area is likely to be affected by any change fixing 56024, so a
> > sensible combined solution might be a good idea.
> 
> This should now be fixed. Now mangled as _Z3foos and _Z3foo10__Poly16_t
> respectively.
> 
> 	.cpu generic+fp+simd
> 	.file	"gpp.cpp"
> 	.text
> 	.align	2
> 	.p2align 3,,7
> 	.global	_Z3foos
> 	.type	_Z3foos, %function
> _Z3foos:
> .LFB3026:
> 	.cfi_startproc
> 	ret
> 	.cfi_endproc
> .LFE3026:
> 	.size	_Z3foos, .-_Z3foos
> 	.align	2
> 	.p2align 3,,7
> 	.global	_Z3foo10__Poly16_t
> 	.type	_Z3foo10__Poly16_t, %function
> _Z3foo10__Poly16_t:
> .LFB3027:
> 	.cfi_startproc
> 	ret
> 	.cfi_endproc
> .LFE3027:
> 	.size	_Z3foo10__Poly16_t, .-_Z3foo10__Poly16_t
> 	.ident	"GCC: (unknown) 5.0.0 20141229 (experimental)"

Sorry, wrong target. Still doesn't seem to be fixed for aarch32.
>From gcc-bugs-return-472325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 06 17:36:09 2015
Return-Path: <gcc-bugs-return-472325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9069 invoked by alias); 6 Jan 2015 17:36:09 -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 8962 invoked by uid 48); 6 Jan 2015 17:36:05 -0000
From: "belagod at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/56025] ARM NEON polynomial types have broken overload resolution
Date: Tue, 06 Jan 2015 17:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: ABI
X-Bugzilla-Severity: normal
X-Bugzilla-Who: belagod at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
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:
Message-ID: <bug-56025-4-q8BsQpHjRU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56025-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56025-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: 2015-01/txt/msg00319.txt.bz2
Content-length: 298

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

--- Comment #4 from Tejas Belagod <belagod at gcc dot gnu.org> ---
The ABI does not define an internal type name for scalar poly types -
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf.
This will need an ABI update.

[Bug target/56025] ARM NEON polynomial types have broken overload resolution

[belagod at gcc dot gnu.org]

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

--- Comment #5 from Tejas Belagod <belagod at gcc dot gnu.org> ---
ACLE states that

"poly8_t and poly16_t are defined as unsigned integer types. It is unspecified
whether these are the same type as uint8_t and  uint16_t for overloading and
mangling purposes"

Presently, poly types are implemented as distinct types in the ARM backend with
default mangling which is wrong. This obviates the need for their own mangling
scheme in the ABI which it does not specify. Therefore, it cannot be modelled
as a distinct type until the ABI says that it is a distinct type. Also, poly8_t
and poly16_t are presently modelled as signed types which is incorrect. When we
change this to an unsigned type, it will be incompatible with legacy anyway wrt
mangling among other things. So, till the time the ABI decides to make poly
types as distinct types, we can model it as an unsigned type or as another type
name for uint8_t or uint16_t. This will disallow overloading of uint8_t and
poly8_t for eg and break current overloads, but correcting poly to unsigned
type is a greater good. This is also future-proof because if the ABI decides to
model poly and unsigned types as distinct types, previously disallowed
overloading will then be allowed which isn't breaking legacy in the broad
sense.