[TESTCASE] AltiVec code uses wrong rtl expression

Daniel Egger degger@fhm.edu
Mon Feb 25 15:22:00 GMT 2002


Hija,

I extended the last testcase a bit to figure out where the code
is miscompiled and it turns out that gcc compiles all vec_mergel
into vmrghh instead of vmrglh. I checked altivec.h as well as
rs6000.[ch] but couldn't find the culprit; in altivec.h the correct
builtin is substitued and in rs6000.[ch] is at least no obvious
typo so it's probably somewhere deeper but I've not the slightest idea
where as the rtl output isn't really clear to me.

Attached are my testcase which should return:
Unaltered
 1  2  3  4  5  6  7  8 
 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31 32 
33 34 35 36 37 38 39 40 
41 42 43 44 45 46 47 48 
49 50 51 52 53 54 55 56 
57 58 59 60 61 62 63 64 

After double transposing
 1  2  3  4  5  6  7  8 
 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31 32 
33 34 35 36 37 38 39 40 
41 42 43 44 45 46 47 48 
49 50 51 52 53 54 55 56 
57 58 59 60 61 62 63 64 

when compiled correctly (double transposition of a 8x8 matrix) but
yields:

Unaltered
 1  2  3  4  5  6  7  8 
 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31 32 
33 34 35 36 37 38 39 40 
41 42 43 44 45 46 47 48 
49 50 51 52 53 54 55 56 
57 58 59 60 61 62 63 64 

After double transposing
 1  9 17 25 33 41 49 57 
 9  1 25 17 41 33 57 49 
17 25  1  9 49 57 33 41 
25 17  9  1 57 49 41 33 
33 41 49 57  1  9 17 25 
41 33 57 49  9  1 25 17 
49 57 33 41 17 25  1  9 
57 49 41 33 25 17  9  1 

For more fun uncomment the c++-commented line which still segfaults
when compiled at -O0.

-- 
Servus,
       Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-c
Size: 2671 bytes
Desc: 
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020225/223d9292/attachment.bin>


More information about the Gcc mailing list