On Thu, Sep 20, 2012 at 10:01 PM, Marc Glisse wrote:
> On Sat, 1 Sep 2012, Marc Glisse wrote:
>
>> I have some issues with the vector-compare-2.c torture test. It passes a
>> vector by value (argument and return type), which is likely to warn
>> (although for some reason it doesn't for me, with to
On Sat, 1 Sep 2012, Marc Glisse wrote:
I have some issues with the vector-compare-2.c torture test. It passes a
vector by value (argument and return type), which is likely to warn (although
for some reason it doesn't for me, with today's compiler). And it takes
-Wno-psabi through a .x file, bu
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(x
That sounds like the right answer.
Hello,
does the attached make sense? It passes booststrap+testsuite, but with
vectors that doesn't prove much...
2012-09-17 Marc Glisse
On Fri, 14 Sep 2012, Jason Merrill wrote:
[decltype of opaque vector]
I think a simple TYPE_MAIN_VARIANT will do, I just need to find where to
add it, and how much to constrain that change. Type deduction in templates
and auto already seem to remove opacity :-)
This patch is OK.
Committed
On 09/14/2012 12:33 PM, Marc Glisse wrote:
Ok, I'll open a bugzilla to remember to try that later.
OK.
The attached just finished the testsuite (changelog unchanged).
This patch is OK.
Jason
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(x
That sounds like the right answer.
Ok, I'll open a bugzilla to remember to try that later.
Type is %qT right? I see a number of %q#T but can't remember where the
doc is. Well, I'
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(x
That sounds like the right answer.
Type is %qT right? I see a number of %q#T but can't remember where the
doc is. Well, I'll try both and see what happens.
Either one works; the # asks for more verbose output.
Jason
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 09:59 AM, Marc Glisse wrote:
* build_vector_type: don't use an opaque vector for the return type of
operator< (not sure what the point was of making it opaque?)
I think the point was to allow conversion of the result to a different ve
On 09/14/2012 09:59 AM, Marc Glisse wrote:
* build_vector_type: don't use an opaque vector for the return type of
operator< (not sure what the point was of making it opaque?)
I think the point was to allow conversion of the result to a different
vector type. Why do you want it not to be op
Here is the patch I just tested. Changes compared to the previous patch
include:
* same_type_ignoring_top_level_qualifiers_p
* build_vector_type: don't use an opaque vector for the return type of
operator< (not sure what the point was of making it opaque?)
* Disable BIT_AND -> TRUTH_AND optimi
On 09/13/2012 07:37 PM, Marc Glisse wrote:
Looks like a latent bug in fold_unary. The following seems to work in
this case.
Looks good.
Jason
On Thu, 13 Sep 2012, Jason Merrill wrote:
Furthermore, this builtin support would be useful for implementing
a C++ class for vector arithmetic, just as it is with std::complex. I'm not
aware of any other portable way to implement such a class.
I forgot to say: it is always possible to do the
On Fri, 14 Sep 2012, Marc Glisse wrote:
While checking my facts for the previous paragraph, I got an ICE :-(
typedef int vec __attribute__((vector_size(16)));
vec const f(vec x,vec y){return xThe same program compiles with gcc (prepare_cmp_insn isn't called), but ICEs
with g++. Looking at the
On Thu, 13 Sep 2012, Jason Merrill wrote:
I don't know either.
+ if (TREE_TYPE (type0) != TREE_TYPE (type1))
I think this should use same_type_ignoring_top_level_qualifiers_p.
Hmm, I assume you mean
same_type_ignoring_top_level_qualifiers_p (type0, type1)
which would replace both th
On 09/13/2012 11:47 AM, Marc Glisse wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
In comments 1 and 7, Richard Guenther didn't seem too enthusiastic about
any vector-related extension to the C++ front-end.
Some users (other PRs) asked instead that we make vector types
class-like so u
On Sep 13, 2012, at 8:47 AM, Marc Glisse wrote:
>> What was the reluctance? It seems clear to me that if we support the type,
>> we should support these operations.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
>
> In comments 1 and 7, Richard Guenther didn't seem too enthusiastic abou
On Thu, 13 Sep 2012, Jason Merrill wrote:
On 08/31/2012 06:20 PM, Marc Glisse wrote:
this patch copies some more vector extensions from the C front-end to
the C++ front-end. There seemed to be some reluctance to add those, but
I guess a patch is the best way to ask
What was the reluctance? I
On 08/31/2012 06:20 PM, Marc Glisse wrote:
this patch copies some more vector extensions from the C front-end to
the C++ front-end. There seemed to be some reluctance to add those, but
I guess a patch is the best way to ask
What was the reluctance? It seems clear to me that if we support the
Any comment?
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02098.html
Maybe separately on the technical and political aspects?
On Sat, 1 Sep 2012, Marc Glisse wrote:
With the patch...
On Sat, 1 Sep 2012, Marc Glisse wrote:
Hello,
this patch copies some more vector extensions from the C fro
With the patch...
On Sat, 1 Sep 2012, Marc Glisse wrote:
Hello,
this patch copies some more vector extensions from the C front-end to the C++
front-end. There seemed to be some reluctance to add those, but I guess a
patch is the best way to ask. Note that I only added the vector x vector
op
Hello,
this patch copies some more vector extensions from the C front-end to the
C++ front-end. There seemed to be some reluctance to add those, but I
guess a patch is the best way to ask. Note that I only added the vector x
vector operations, not the vector x scalar ones.
I have some issues
21 matches
Mail list logo
