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

["belagod at gcc dot gnu.org" <gcc-bugzilla@gcc.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)"