Hi Marc, Thank you for the reply. So it's a known g++ issue with a candidate patch. Looking at the patch, I was wondering, what precludes the generic vector types form being proper arithmetic types?
Regards, Martin On 26 May 2016 at 09:02, Marc Glisse <marc.gli...@inria.fr> wrote: > 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