On 09/06/2013 08:58 PM, Joern Rennecke wrote:
vector_targets_convertible_p is used for pointer types. The callers
do a hop, skip and dance to check that the qualifiers are satisfactory,
while OTOH vector_targets_convertible_p ignores the number of elements
in the vectors. That's fine with
On 09/05/2013 10:50 AM, Joern Rennecke wrote:
(vector_types_compatible_elements_p): New function.
Why do we need this as well as vector_types_convertible_p? For that
matter, why do we need both vector_types_convertible_p and
vector_targets_convertible_p?
Jason
Quoting Jason Merrill ja...@redhat.com:
On 09/05/2013 10:50 AM, Joern Rennecke wrote:
(vector_types_compatible_elements_p): New function.
Why do we need this as well as vector_types_convertible_p? For that
matter, why do we need both vector_types_convertible_p and
On 09/05/13 15:50, Joern Rennecke wrote:
Apart from Paolo Carlini's suggestion to improve the wording of the ChangeLog,
this patch hasn't been reviewed for more than a week:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html
I don't think the issue is whether they should be treated as
Apart from Paolo Carlini's suggestion to improve the wording of the ChangeLog,
this patch hasn't been reviewed for more than a week:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html
Quoting Nathan Sidwell nat...@acm.org:
On 09/05/13 15:50, Joern Rennecke wrote:
Apart from Paolo Carlini's suggestion to improve the wording of the
ChangeLog,
this patch hasn't been reviewed for more than a week:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html
I suppose the
Quoting Marc Glisse marc.gli...@inria.fr:
On Mon, 26 Aug 2013, Joern Rennecke wrote:
Quoting Marc Glisse marc.gli...@inria.fr:
The issue seems larger than just short/int. On x86, (ll)l fails to
compile for a vector of long, with ll that has opaque type vector of
int, that seems wrong.
I
Hi,
On 08/28/2013 12:29 AM, Joern Rennecke wrote:
* c-common.h: (same_scalar_type_ignoring_signedness): Delete prototype.
(vector_types_compatible_elements_p): Prototype.
Sorry for nitpicking, but since we are now using C++ I think declaration
is more correct than prototype.
avr currently shows the following failure:
FAIL: c-c++-common/vector-scalar.c -Wc++-compat (test for excess errors)
Excess errors:
/home/amylaar/atmel/4.8/unisrc-mainline/gcc/testsuite/c-c++-common/vector-scalar
.c:9:34: error: invalid operands to binary | (have '__vector(8) int'
and 'veci')
On Mon, 26 Aug 2013, Joern Rennecke wrote:
avr currently shows the following failure:
FAIL: c-c++-common/vector-scalar.c -Wc++-compat (test for excess errors)
Excess errors:
/home/amylaar/atmel/4.8/unisrc-mainline/gcc/testsuite/c-c++-common/vector-scalar
.c:9:34: error: invalid operands to
Quoting Marc Glisse marc.gli...@inria.fr:
The issue seems larger than just short/int. On x86, (ll)l fails to
compile for a vector of long, with ll that has opaque type vector of
int, that seems wrong.
I don't understand what you mean here. Could you post the actual code sample?
On Mon, 26 Aug 2013, Joern Rennecke wrote:
Quoting Marc Glisse marc.gli...@inria.fr:
The issue seems larger than just short/int. On x86, (ll)l fails to
compile for a vector of long, with ll that has opaque type vector of
int, that seems wrong.
I don't understand what you mean here. Could
12 matches
Mail list logo
