Hello, gcc's vector extension, primarily developed for C, is only partially available in C++. It is missing the very useful subscript operator and __builtin_shuffle (and possibly other things). It would be great if C++ could catch up. (then I don't know if there is any plan to map some libstdc++ types to those, probably hard for ABI reasons)
Hmm, I thought we did the C++ extension mainly for the SPU stuff and think that C++ language features are powerful enough to implement those extensions themselves.
It's probably doable, but it sounds like you have to duplicate all the logic that is currently in the various backends (and some in the C front-end and the middle-end I guess). The shuffle function has a different implementation for all versions of all architectures that provide vectorization. I am not sure how good an idea it is to decide that all this logic has to be coded twice, once for the C vector extension and one for the C++ library, where the 2 codes would be extremely different. Or I probably didn't quite get what you meant. Would you mind giving a few more details on how one would go about implementing it?
All vector support should also be in the C++ front-end. Can you give an example of something which does not work? Templates with vectors work already too.
(In reply to comment #3) > All vector support should also be in the C++ front-end. Can you give an > example of something which does not work? Templates with vectors work already > too. #include <x86intrin.h> double f(){ __m256d x={1,2,3,4}; __m256i m={1,2,3,0}; return __builtin_shuffle(x,m)[0]; } error: ‘__builtin_shuffle’ was not declared in this scope If I just return x[0], I get: error: invalid types ‘__m256d {aka __vector(4) double}[int]’ for array subscript
I am going to mark this as a regression because before both the C++ front-end and C front-ends were working with all vector extensions. This is really bad news if only the C front-end got an improvement and the C++ front-end did not.
(In reply to comment #5) > I am going to mark this as a regression because before both the C++ front-end > and C front-ends were working with all vector extensions. This is really bad > news if only the C front-end got an improvement and the C++ front-end did not. Note that at least the documentation is honest about it: http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html "In C it is possible [...]" "For the convenience in C [...]" "In GNU C [...]"
It's clearly not a regression - it's an enhancement request (and language extensions in C++ are so much more fragile because of the power of C++ and possible interaction with other language features).
At least __builtin_shuffle is hardly going to clash with any language feature, it is an overloaded set of builtins for vector types, nothing else.
*** Bug 51700 has been marked as a duplicate of this bug. ***
Created attachment 27176 [details] subscript This patch (a simple copy of a paragraph from the C front-end) seems sufficient to add vector subscript support to the C++ front-end. At least, on the related testcases I could find in the testsuite (vector-init-2.c, vector-subscript-[123].c), g++ produces the same results as gcc (some error messages have different content, but the same meaning, and the carets point to '[' in C and ']' in C++). I don't know if any of the functions called have more idiomatic counterparts in the C++ front-end. __builtin_shuffle seems a bit harder to move for someone not familiar with the code. Note that in C++ operator[] can only be a member function, which means we don't need to worry about overloading or anything like that.
(In reply to comment #10) > Created attachment 27176 [details] > subscript > > This patch (a simple copy of a paragraph from the C front-end) seems sufficient > to add vector subscript support to the C++ front-end. At least, on the related > testcases I could find in the testsuite (vector-init-2.c, > vector-subscript-[123].c), g++ produces the same results as gcc (some error > messages have different content, but the same meaning, and the carets point to > '[' in C and ']' in C++). If it is indeed a copy, you should move the code c-common.c and share it. The C-family FEs should share as much code as possible. Also, testcases that work on both languages, should move to testsuite/c-c++-common/
(In reply to comment #11) > If it is indeed a copy, you should move the code c-common.c and share it. The > C-family FEs should share as much code as possible. I agree on the principle. If more code was shared, C++ would already support this feature ;-) On the other hand, here I am copying a small block of code in the middle of a function. Making just that paragraph common wouldn't make much sense imho. Factoring most of (cp_)build_array_ref might make sense, but requires someone with a better understanding of the FEs, because there are slight differences that may or may not be relevant.
(In reply to comment #12) > On the other hand, here I am copying a small block of code in the middle of a > function. Making just that paragraph common wouldn't make much sense imho. > Factoring most of (cp_)build_array_ref might make sense, but requires someone > with a better understanding of the FEs, because there are slight differences > that may or may not be relevant. Something is better than nothing. I respectfully disagree, there are more than 10 lines of code there. If some change is ever required in those and the code is not shared, only one version will be changed. You can call the function vector_to_underlying_pointer_type() or something like that. Then you don't even need a comment.
Created attachment 27178 [details] subscript 2 (Manuel-compliant)
:) Thanks for making me happy and sorry for being a PITA. Are you planning to send it to gcc-patches for approval or are you not happy with it yet?
(In reply to comment #15) > Are you planning to send it to gcc-patches for approval or are you not happy > with it yet? There is the problem of moving the testcases. What svn diff prints is nonsense, so I guess I should just write the Changelog and let whoever commits do the moves? The following can move to c-c++-common: gcc.dg/vector-2.c gcc.dg/vector-subscript-2.c gcc.dg/vector-3.c gcc.dg/vector-subscript-3.c gcc.dg/vector-init-1.c gcc.dg/vector-4.c gcc.dg/vector-init-2.c gcc.dg/vector-1.c gcc.dg/vector-subscript-1.c with these minor modifications: Index: c-c++-common/vector-subscript-1.c =================================================================== --- c-c++-common/vector-subscript-1.c (revision 186523) +++ c-c++-common/vector-subscript-1.c (working copy) @@ -6,7 +6,7 @@ float vf(vector float a) { - return 0[a]; /* { dg-error "subscripted value is neither array nor pointer nor vector" } */ + return 0[a]; /* { dg-error "subscripted value is neither array nor pointer nor vector|invalid types .* for array subscript" } */ } Index: c-c++-common/vector-3.c =================================================================== --- c-c++-common/vector-3.c (revision 186523) +++ c-c++-common/vector-3.c (working copy) @@ -2,4 +2,7 @@ /* Check that we error out when using vector_size on the bool type. */ +#ifdef __cplusplus +#define _Bool bool +#endif __attribute__((vector_size(16) )) _Bool a; /* { dg-error "" } */ And now I should actually bootstrap and run the testsuite ;-)
(In reply to comment #16) > (In reply to comment #15) > > Are you planning to send it to gcc-patches for approval or are you not happy > > with it yet? > > There is the problem of moving the testcases. What svn diff prints is nonsense, > so I guess I should just write the Changelog and let whoever commits do the > moves? Yep, just mention the moves in the changelog, and only show the diffs of the modifications (like you did above). > And now I should actually bootstrap and run the testsuite ;-) Good luck! BTW, it may be handy to get an account in the GCC compile farm: http://gcc.gnu.org/wiki/CompileFarm and I have a script that makes very easy to bootstrap+regtest: $ gccfarming bootstrap; PATCH=~/mypatch.diff gccfarming bootstrap you get two directories revsion/ and revisionM-mypatch/, then you do contrib/compare_tests revision/ revisionM-mypatch/ and check for problems. Let me know if you are interested.
(In reply to comment #17) > > And now I should actually bootstrap and run the testsuite ;-) > Good luck! It worked fine, same failures as I got the other day for another patch. > BTW, it may be handy to get an account in the GCC compile farm: > http://gcc.gnu.org/wiki/CompileFarm Thanks for the advice. I looked into it once, but don't currently need it: make -j check leaves my 3 year old desktop at least 60% idle, and the few architectures that could tempt me are not available in the farm (an x64 with AVX? a sparc with VIS3?).
Created attachment 27217 [details] shuffle With this patch, g++ passes the few __builtin_shuffle tests I tried, and generates generic code for non-constant indexes and special code for constant indexes. I don't really know what to do about the testsuite. The tests exercise the backend a lot, and it probably doesn't make sense to run everything with both gcc and g++. But we still want to test that g++ accepts the syntax, and maybe even that it handles constants well. Content of the patch: - move c_build_vec_perm_expr to c-common and condition the maybe_const stuff to the dialect - adapt the C RID_BUILTIN_SHUFFLE parser code to the C++ FE (the 2 are different enough that it isn't easy to share) - remove the C_ONLY tag from __builtin_shuffle As usual, my limited knowledge of the compiler means I may have missed fundamental things.
(In reply to comment #19) > Created attachment 27217 [details] > shuffle Doesn't work with -std=c++11, which requires: --- semantics.c (revision 186667) +++ semantics.c (working copy) @@ -5603,11 +5603,12 @@ float_const_decimal64_p (void) bool literal_type_p (tree t) { if (SCALAR_TYPE_P (t) - || TREE_CODE (t) == REFERENCE_TYPE) + || TREE_CODE (t) == REFERENCE_TYPE + || TREE_CODE (t) == VECTOR_TYPE) return true; if (CLASS_TYPE_P (t)) { t = complete_type (t); gcc_assert (COMPLETE_TYPE_P (t) || errorcount); @@ -8487,10 +8488,11 @@ potential_constant_expression_1 (tree t, want_rval, flags)) return false; return true; case FMA_EXPR: + case VEC_PERM_EXPR: for (i = 0; i < 3; ++i) if (!potential_constant_expression_1 (TREE_OPERAND (t, i), true, flags)) return false; return true; And then I still need to write a cxx_eval_vec_perm function so the result of __builtin_shuffle can be constexpr. I haven't seen how the C front-end handles shuffles of constants. Maybe a "sorry" would do for now.
(In reply to comment #19) > With this patch, g++ passes the few __builtin_shuffle tests I tried, and > generates generic code for non-constant indexes and special code for constant > indexes. I don't really know what to do about the testsuite. The tests exercise > the backend a lot, and it probably doesn't make sense to run everything with > both gcc and g++. But we still want to test that g++ accepts the syntax, and > maybe even that it handles constants well. What does it mean "exercise the backend a lot"? Do you mean it takes a lot of time? I haven't looked at the tests, but I think it is not a problem to run compile-only tests with both gcc and g++. > As usual, my limited knowledge of the compiler means I may have missed > fundamental things. It looks pretty good to me.
(In reply to comment #20) > And then I still need to write a cxx_eval_vec_perm function so the result of > __builtin_shuffle can be constexpr. I haven't seen how the C front-end handles > shuffles of constants. Maybe a "sorry" would do for now. Making vectors literals is too much for now, the following seems sufficient as long as they are not. --- cp/semantics.c (revision 186667) +++ cp/semantics.c (working copy) @@ -8262,10 +8262,11 @@ potential_constant_expression_1 (tree t, case TRANSACTION_EXPR: case IF_STMT: case DO_STMT: case FOR_STMT: case WHILE_STMT: + case VEC_PERM_EXPR: if (flags & tf_error) error ("expression %qE is not a constant-expression", t); return false; case TYPEID_EXPR:
(In reply to comment #21) > What does it mean "exercise the backend a lot"? Do you mean it takes a lot of > time? I think so. > I haven't looked at the tests, but I think it is not a problem to run > compile-only tests with both gcc and g++. compile-time tests are not always sufficient. The __builtin_shuffle tests are spread in: gcc.dg{,/torture} gcc.target/{i386,powerpc} gcc.c-torture/{compile,execute} I assume the tests in gcc.dg can move to c-c++-common. The target tests should stay in target. Not sure about gcc.c-torture. But one interesting thing to test is if the front-end passes the arguments as constants and thus the backend can use specialized code instead of the slow generic one. And this kind of test seems necessarily target-specific. Bah, I guess I shouldn't ask for too much and moving the gcc.dg tests would be enough.
Author: jason Date: Mon Apr 30 17:23:28 2012 New Revision: 186994 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186994 Log: PR c++/51033 gcc/ * c-typeck.c (build_array_ref): Call convert_vector_to_pointer_for_subscript. gcc/c-family * c-common.c (convert_vector_to_pointer_for_subscript): New function. * c-common.h (convert_vector_to_pointer_for_subscript): Declare it. gcc/cp/ * typeck.c (cp_build_array_ref): Handle VECTOR_TYPE. * decl2.c (grok_array_decl): Likewise. Added: trunk/gcc/testsuite/c-c++-common/vector-1.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-1.c trunk/gcc/testsuite/c-c++-common/vector-2.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-2.c trunk/gcc/testsuite/c-c++-common/vector-3.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-3.c trunk/gcc/testsuite/c-c++-common/vector-4.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-4.c trunk/gcc/testsuite/c-c++-common/vector-init-1.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-init-1.c trunk/gcc/testsuite/c-c++-common/vector-init-2.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-init-2.c trunk/gcc/testsuite/c-c++-common/vector-subscript-1.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-subscript-1.c trunk/gcc/testsuite/c-c++-common/vector-subscript-2.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-subscript-2.c trunk/gcc/testsuite/c-c++-common/vector-subscript-3.c - copied, changed from r186993, trunk/gcc/testsuite/gcc.dg/vector-subscript-3.c trunk/gcc/testsuite/g++.dg/cpp0x/vt-51314.C Removed: trunk/gcc/testsuite/gcc.dg/vector-1.c trunk/gcc/testsuite/gcc.dg/vector-2.c trunk/gcc/testsuite/gcc.dg/vector-3.c trunk/gcc/testsuite/gcc.dg/vector-4.c trunk/gcc/testsuite/gcc.dg/vector-init-1.c trunk/gcc/testsuite/gcc.dg/vector-init-2.c trunk/gcc/testsuite/gcc.dg/vector-subscript-1.c trunk/gcc/testsuite/gcc.dg/vector-subscript-2.c trunk/gcc/testsuite/gcc.dg/vector-subscript-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/typeck.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog
(In reply to comment #19) > Created attachment 27217 [details] > shuffle > > With this patch, g++ passes the few __builtin_shuffle tests I tried, and > generates generic code for non-constant indexes and special code for constant > indexes. I don't really know what to do about the testsuite. The tests exercise > the backend a lot, and it probably doesn't make sense to run everything with > both gcc and g++. But we still want to test that g++ accepts the syntax, and > maybe even that it handles constants well. > > Content of the patch: > - move c_build_vec_perm_expr to c-common and condition the maybe_const stuff to > the dialect > - adapt the C RID_BUILTIN_SHUFFLE parser code to the C++ FE (the 2 are > different enough that it isn't easy to share) > - remove the C_ONLY tag from __builtin_shuffle > > As usual, my limited knowledge of the compiler means I may have missed > fundamental things. Are you planning on submitting the shuffle patch as well ?
(In reply to comment #23) > (In reply to comment #21) > > What does it mean "exercise the backend a lot"? Do you mean it takes a lot of > > time? > > I think so. > > > I haven't looked at the tests, but I think it is not a problem to run > > compile-only tests with both gcc and g++. > > compile-time tests are not always sufficient. > > The __builtin_shuffle tests are spread in: > gcc.dg{,/torture} > gcc.target/{i386,powerpc} > gcc.c-torture/{compile,execute} > > I assume the tests in gcc.dg can move to c-c++-common. The target tests should > stay in target. Not sure about gcc.c-torture. > > But one interesting thing to test is if the front-end passes the arguments as > constants and thus the backend can use specialized code instead of the slow > generic one. And this kind of test seems necessarily target-specific. Bah, I > guess I shouldn't ask for too much and moving the gcc.dg tests would be enough. Patch posted for comments here : http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00903.html
Author: ramana Date: Fri Jun 15 16:43:36 2012 New Revision: 188671 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188671 Log: 2012-06-15 Marc Glisse <marc.glisse@inria.fr> PR c++/51033 * c-typeck.c (c_build_vec_perm_expr): Move to c-family/c-common.c. * c-tree.h (c_build_vec_perm_expr): Move to c-family/c-common.h. cp/ 2012-06-15 Marc Glisse <marc.glisse@inria.fr> PR c++/51033 * semantics.c (literal_type_p): Handle VECTOR_TYPE. (potential_constant_expression_1): Handle VEC_PERM_EXPR. * parser.c (cp_parser_postfix_expression): Handle RID_BUILTIN_SHUFFLE. c-family 2012-06-15 Marc Glisse <marc.glisse@inria.fr> PR c++/51033 * c-common.h (c_build_vec_perm_expr): Move decl here. * c-common.c (c_build_vec_perm_expr): Move definition here. 2012-06-15 Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org> PR c++/51033 * c-c++-common/torture/vshuf-16.inc: Move from gcc.c-torture/execute/. * c-c++-common/torture/vshuf-2.inc: Likewise. * c-c++-common/torture/vshuf-4.inc: Likewise. * c-c++-common/torture/vshuf-8.inc: Likewise. * c-c++-common/torture/vshuf-main.inc: Likewise. * c-c++-common/torture/vshuf-v16hi.c: Likewise. * c-c++-common/torture/vshuf-v16qi.c: Likewise. * c-c++-common/torture/vshuf-v2df.c: Likewise. * c-c++-common/torture/vshuf-v2di.c: Likewise. * c-c++-common/torture/vshuf-v2sf.c: Likewise. * c-c++-common/torture/vshuf-v2si.c: Likewise. * c-c++-common/torture/vshuf-v4df.c: Likewise. * c-c++-common/torture/vshuf-v4di.c: Likewise. * c-c++-common/torture/vshuf-v4hi.c: Likewise. * c-c++-common/torture/vshuf-v4sf.c: Likewise. * c-c++-common/torture/vshuf-v4si.c: Likewise. * c-c++-common/torture/vshuf-v8hi.c: Likewise. * c-c++-common/torture/vshuf-v8qi.c: Likewise. * c-c++-common/torture/vshuf-v8si.c: Likewise. Added: trunk/gcc/testsuite/c-c++-common/torture/vshuf-16.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-16.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-2.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-2.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-4.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-4.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-8.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-8.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-main.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-main.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-v16hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16qi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2df.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2df.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2di.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2sf.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2sf.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2si.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4df.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4df.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4di.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4di.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4sf.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4sf.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4si.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8qi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8qi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8si.c Removed: trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-16.inc trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-2.inc trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-4.inc trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-8.inc trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-main.inc trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16hi.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16qi.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2df.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2di.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2sf.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2si.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4df.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4di.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4hi.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4sf.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4si.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8hi.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8qi.c trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8si.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
Author: ramana Date: Wed Jun 27 14:19:17 2012 New Revision: 189017 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189017 Log: 2012-06-27 Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org> PR C++/51033 * semantics.c (constexpr_call): Fix typo in comment. (cxx_eval_vec_perm_expr): New. (cxx_eval_constant_expression): Fold VEC_PERM_EXPRs. 2012-06-27 Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org> PR c++/51033. * g++.dg/torture/vshuf-16.inc: New test. * g++.dg/torture/vshuf-2.inc: New test. * g++.dg/torture/vshuf-4.inc: New test. * g++.dg/torture/vshuf-8.inc: New test. * g++.dg/torture/vshuf-main.inc: New test. * g++.dg/torture/vshuf-v16hi.C: New test. * g++.dg/torture/vshuf-v16qi.C: New test. * g++.dg/torture/vshuf-v2df.C: New test. * g++.dg/torture/vshuf-v2di.C: New test. * g++.dg/torture/vshuf-v2sf.C: New test. * g++.dg/torture/vshuf-v2si.C: New test. * g++.dg/torture/vshuf-v4df.C: New test. * g++.dg/torture/vshuf-v4di.C: New test. * g++.dg/torture/vshuf-v4sf.C: New test. * g++.dg/torture/vshuf-v4si.C: New test. * g++.dg/torture/vshuf-v8hi.C: New test. * g++.dg/torture/vshuf-v8qi.C: New test. * g++.dg/torture/vshuf-v8si.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/vshuf-16.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-2.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-4.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-8.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-main.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-v16hi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v16qi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2df.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2di.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2sf.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2si.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4df.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4di.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4sf.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4si.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8hi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8qi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8si.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
I guess both subscript and shuffle are in, so I can close. There is already PR 53094 to track the constexpr issues.
(In reply to comment #3) > All vector support should also be in the C++ front-end. Can you give an > example of something which does not work? Templates with vectors work already > too. Another example is binary operators between scalar and vectors. In C the scalar is automatically treated as a vector, but in C++ it results in a type error.
(In reply to comment #30) > Another example is binary operators between scalar and vectors. In C the scalar > is automatically treated as a vector, but in C++ it results in a type error. That's been fixed already. I think the C++ front-end currently (4.8) supports _more_ operations on vectors than the C front-end (in particular ?: ).
(In reply to comment #31) > (In reply to comment #30) > > Another example is binary operators between scalar and vectors. In C the scalar > > is automatically treated as a vector, but in C++ it results in a type error. > > That's been fixed already. I think the C++ front-end currently (4.8) supports > _more_ operations on vectors than the C front-end (in particular ?: ). Ah, right. I was testing with the wrong compiler. For simplicity I will just restrict our use of vector extensions to g++ >=4.8. Thanks for the great work. Looking forward to 4.8.0.