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.
