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