Implicit conversion to a generic vector type

[martin krastev]

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.

Thanks,
Martin

Re: Implicit conversion to a generic vector type

[martin krastev]

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

Re: Implicit conversion to a generic vector type

[martin krastev]

A new arithmeticish type would take more effort, I understand. Marc,
are there plans to incorporate your patch, perhaps in an extended
form, in a release any time soon? My apologies if I'm addressing these
questions to the wrong person.

Regards,
Martin

On 26 May 2016 at 11:11, Marc Glisse  wrote:
> On Thu, 26 May 2016, martin krastev wrote:
>
>> 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?
>
>
> In some cases vectors act like arithmetic types (operator+, etc), and in
> others they don't (conversions in general). We have scalarish_type_p for
> things that are scalars or vectors, we could add arithmeticish_type_p ;-)
>
> (I think the name arithmetic comes directly from the standard, so we don't
> want to change its meaning)
>
> --
> Marc Glisse

Issues building gcc natively on mipsel

[martin krastev]

Hello,

I'm trying to build gcc-7.3.0 (md5 747d5010b7c6938b480bc6e4d7c4be9a of
tar.gz) natively on a MACHTYPE=mipsel-unknown-linux-gnu MIPS p5600 machine
under Debian Stretch. I'm getting an illegal instruction during libstdc++
build phase:

libtool: compile:  /home/gru/proj/gcc_build/./gcc/xgcc -shared-libgcc
-B/home/gru/proj/gcc_build/./gcc -nostdinc++
-L/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/src
-L/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/src/.libs
-L/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/mipsel-linux-gnu/bin/ -B/usr/local/mipsel-linux-gnu/lib/
-isystem /usr/local/mipsel-linux-gnu/include -isystem
/usr/local/mipsel-linux-gnu/sys-include
-I/home/gru/proj/gcc-7.3.0/libstdc++-v3/../libgcc
-I/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include/mipsel-linux-gnu
-I/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include
-I/home/gru/proj/gcc-7.3.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-std=gnu++14 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-ops.lo -g -O2 -D_GNU_SOURCE -minterlink-mips16 -c
/home/gru/proj/gcc_build/../gcc-7.3.0/libstdc++-v3/src/filesystem/cow-ops.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o cow-ops.o
In file included from
/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include/vector:64:0,
 from
/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include/experimental/bits/fs_path.h:39,
 from
/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include/experimental/filesystem:39,
 from
/home/gru/proj/gcc_build/../gcc-7.3.0/libstdc++-v3/src/filesystem/dir.cc:29,
 from
/home/gru/proj/gcc_build/../gcc-7.3.0/libstdc++-v3/src/filesystem/cow-dir.cc:26:
/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:
In member function 'void std::vector<_Tp,
_Alloc>::_M_move_assign(std::vector<_Tp, _Alloc>&&, std::true_type) [with
_Tp = std::experimental::filesystem::v1::path::_Cmpt; _Alloc =
std::allocator]':
/home/gru/proj/gcc_build/mipsel-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1531:9:
internal compiler error: Illegal instruction
  vector __tmp(get_allocator());
 ^
0x159a473 crash_signal
/home/gru/proj/gcc_build/../gcc-7.3.0/gcc/toplev.c:337
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:523: recipe for target 'cow-dir.lo' failed
make[6]: *** [cow-dir.lo] Error 1


I have configured and launched the build as:

$ CPATH=/usr/include/mipsel-linux-gnu/
LIBRARY_PATH=/usr/lib/mipsel-linux-gnu/ $PWD/../gcc-7.3.0/configure
--enable-languages=c,c++ --with-float=hard --disable-multiarch
--target=mipsel-linux-gnu
$ CPATH=/usr/include/mipsel-linux-gnu
LIBRARY_PATH=/usr/lib/mipsel-linux-gnu make -j2

I've clearly misconfigured the build -- xgcc ended up with a wrong ISA, but
I can't figure out how. What am I missing?

Best regards,
Martin

gcc 4.4.0 loop-unrolling optimizations peculiarity observed

[martin krastev]

gcc version: powerpc-apple-darwin8.11.0-gcc-4.4.0 (GCC) 4.4.0 20090116
(experimental)
version is a macports (formerly darwin ports) build of gcc4.4.0 on an
OSX 10.4.11 ppc7450 host

Following C function produces different code depending on the use of
'loop_Ai' vs 'direct_assignment_Ai' snippets:

float a[4][4] __attribute__ ((aligned (16)));
float b[4][4] __attribute__ ((aligned (16)));

float c[4][4] __attribute__ ((aligned (16)));

inline static void
mmul(
float (&c)[4][4],
const float (&a)[4][4],
const float (&b)[4][4])
{
// iterate by product's rows
for (unsigned i = 0; i < 4; i++)
{
register float ai[4][4];

// swizzle each element of the i-th row of A into a
full-dimensional vector
for (unsigned j = 0; j < 4; j++)

// direct_assignment_Ai:
/*  ai[j][0] = ai[j][1] = ai[j][2] = ai[j][3] = a[i][j];
*/
// loop_Ai:
for (unsigned k = 0; k < 4; k++)
ai[j][k] = a[i][j];

// multiply the first element of the i-th row of A by the first row of B
for (unsigned k = 0; k < 4; k++)
{
c[i][k] = ai[0][k] * b[0][k];
}

// multiply-add all subsequent elements of the i-th row of A
by their respective rows of B
for (unsigned j = 1; j < 4; j++)
{
for (unsigned k = 0; k < 4; k++)
{
c[i][k] += ai[j][k] * b[j][k];
}
}
}
}

/code

Observed ~10% performance degradation when using 'loop_Ai' instead of
'direct_assignment_Ai'. From what I can tell, the differences in the
generated ppc code constitute mainly instruction scheduling.

Following optimization-related compiler options were used for the test:

-fno-exceptions -fno-rtti -faltivec -maltivec -mtune=7450 -O3
-fmessage-length=0 -funroll-loops -ffast-math -fstrict-aliasing
-ftree-vectorize -ftree-vectorizer-verbose=3 -fvisibility=hidden
-fvisibility-inlines-hidden -fno-threadsafe-statics

Full test app code and resulting .s files available upon request. For
the record, the intended vectorization fails, so resulting code is
entirely scalar, but it is rich on fused multiply-add's.

-martin