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