Implicit conversion to a generic vector type

[Marc Glisse]

On Thu, 26 May 2016, martin krastev wrote:

> Hello,
>
> I've been scratching my head over an implicit conversion issue,
> depicted in the following code:
>
>
> typedef __attribute__ ((vector_size(4 * sizeof(int)))) int generic_int32x4;
>
> struct Foo {
>    Foo() {
>    }
>    Foo(const generic_int32x4& src) {
>    }
>    operator generic_int32x4() const {
>        return (generic_int32x4){ 42 };
>    }
> };
>
> struct Bar {
>    Bar() {
>    }
>    Bar(const int src) {
>    }
>    operator int() const {
>        return 42;
>    }
> };
>
> int main(int, char**) {
>
>    const Bar b = Bar() + Bar();
>    const generic_int32x4 v = (generic_int32x4){ 42 } + (generic_int32x4){ 42 };
>    const Foo e = generic_int32x4(Foo()) + generic_int32x4(Foo());
>    const Foo f = Foo() + Foo();
>    const Foo g = (generic_int32x4){ 42 } + Foo();
>    const Foo h = Foo() + (generic_int32x4){ 42 };
>    return 0;
> }
>
> In the above, the initialization expression for local 'b' compiles as
> expected, and so do the expressions for locals 'v' and 'e'. The
> initializations of locals 'f', 'g' and 'h', though, fail to compile
> (under g++-6.1.1, likewise under 5.x and 4.x) with:
>
> $ g++-6 xxx.cpp
> xxx.cpp: In function ‘int main(int, char**)’:
> xxx.cpp:28:22: error: no match for ‘operator+’ (operand types are
> ‘Foo’ and ‘Foo’)
>  const Foo f = Foo() + Foo();
>                ~~~~~~^~~~~~~
> xxx.cpp:29:40: error: no match for ‘operator+’ (operand types are
> ‘generic_int32x4 {aka __vector(4) int}’ and ‘Foo’)
>  const Foo g = (generic_int32x4){ 42 } + Foo();
>                                 ~~~~~~~^~~~~~~
> xxx.cpp:30:22: error: no match for ‘operator+’ (operand types are
> ‘Foo’ and ‘generic_int32x4 {aka __vector(4) int}’)
>  const Foo h = Foo() + (generic_int32x4){ 42 };
>                ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
>
> Apparently there is some implicit conversion rule that stops g++ from
> doing the expected implicit conversions, but I can't figure out which
> rule that is. The fact clang handles the code without an issue does
> not help either. Any help will be appreciated.

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

-- 
Marc Glisse