Re: [PATCH, AArch64] Fix for PR67896 (C++ FE cannot distinguish __Poly{8,16,64,128}_t types)
Hi James,
> This patch looks technically correct to me, though there is a small
> style issue to correct (in-line below), and your ChangeLogs don't fit
> our usual style.
thank you very much for the useful comments. I'm attaching a new
version of the patch with the style issues (hopefully) ironed out.
Kind regards,
gcc/ChangeLog:
2016-01-19 Roger Ferrer Ibáñez <rofir...@gmail.com>
PR target/67896
* config/aarch64/aarch64-builtins.c
(aarch64_init_simd_builtin_types): Do not set structural
equality to __Poly{8,16,64,128}_t types.
gcc/testsuite/ChangeLog:
2016-01-19 Roger Ferrer Ibáñez <rofir...@gmail.com>
PR target/67896
* gcc.target/aarch64/simd/pr67896.C: New.
--
Roger Ferrer Ibáñez
From 72c065f6a3f9d168baf357de1b567faa6042c03b Mon Sep 17 00:00:00 2001
From: Roger Ferrer Ibanez <roger.fer...@bsc.es>
Date: Wed, 20 Jan 2016 21:11:42 +0100
Subject: [PATCH] Do not set structural equality on polynomial types
---
gcc/config/aarch64/aarch64-builtins.c | 10 ++
gcc/testsuite/gcc.target/aarch64/simd/pr67896.C | 7 +++
2 files changed, 13 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index bd7a8dd..40272ed 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -610,14 +610,16 @@ aarch64_init_simd_builtin_types (void)
enum machine_mode mode = aarch64_simd_types[i].mode;
if (aarch64_simd_types[i].itype == NULL)
- aarch64_simd_types[i].itype =
- build_distinct_type_copy
- (build_vector_type (eltype, GET_MODE_NUNITS (mode)));
+ {
+ aarch64_simd_types[i].itype
+ = build_distinct_type_copy
+ (build_vector_type (eltype, GET_MODE_NUNITS (mode)));
+ SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
+ }
tdecl = add_builtin_type (aarch64_simd_types[i].name,
aarch64_simd_types[i].itype);
TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
- SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
}
#define AARCH64_BUILD_SIGNED_TYPE(mode) \
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
new file mode 100644
index 000..1f916e0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
@@ -0,0 +1,7 @@
+typedef __Poly8_t A;
+typedef __Poly16_t A; /* { dg-error "conflicting declaration" } */
+typedef __Poly64_t A; /* { dg-error "conflicting declaration" } */
+typedef __Poly128_t A; /* { dg-error "conflicting declaration" } */
+
+typedef __Poly8x8_t B;
+typedef __Poly16x8_t B; /* { dg-error "conflicting declaration" } */
--
2.1.4
[PATCH] Fix for PR67896 (C++ FE cannot distinguish __Poly{8,16,64,128}_t types)
Hi,
aarch64-builtins.c defines several SIMD builtin types. Among these
SIMD types there are the polynomials __Poly{8,16,64,128}_t. These are
built by a call to build_distinct_type_copy
(unsigned_int{Q,H,D,T}I_type_node), respectively, i.e. they are not
VECTOR_TYPEs. A later loop, traverses an array containing all the SIMD
types and skips those types for which a VECTOR_TYPE does not have to
be built: this is, types __Poly{8,16,64,128}_t. That same loop does
SET_TYPE_STRUCTURAL_EQUALITY on the newly created vector type, but it
does this unconditionally, thus setting TYPE_CANONICAL of types
__Poly{8,16,64,128}_t to NULL.
The net effect of this is that the C++ FE is unable to distinguish
between all __Poly{8,16,64,128}_t and between vector types with the
same number of elements but different polynomial type as element type
(like __Poly8x8_t vs __Poly16x8_t). Note that sizeof (correctly)
returns different values for all these types. This patch simply
protects SET_TYPE_STRUCTURAL_EQUALITY inside the branch that creates
the vector type.
I have bootstrapped and regression tested this on a small board
aarch64-unknown-linux-gnu host without new regressions.
P.S.: I haven't signed the copyright assignment to the FSF. The change
is really small but I can do the paperwork if required.
Kind regards,
gcc/ChangeLog:
2016-01-19 Roger Ferrer Ibáñez <rofir...@gmail.com>
PR aarch64/67896
* aarch64-builtins.c (aarch64_init_simd_builtin_types): Do not set
structural equality to __Poly{8,16,64,128}_t types
gcc/testsuite/ChangeLog:
2016-01-19 Roger Ferrer Ibáñez <rofir...@gmail.com>
PR aarch64/67896
* pr67896.C: New test
--
Roger Ferrer Ibáñez
From 22edde54bcc50fc41a8195d84d278bd1a1dfeb13 Mon Sep 17 00:00:00 2001
From: Roger Ferrer Ibanez <roger.fer...@bsc.es>
Date: Thu, 14 Jan 2016 21:54:56 +0100
Subject: [PATCH] Do not mark polynomial types as requiring structural equality
---
gcc/config/aarch64/aarch64-builtins.c | 8 +---
gcc/testsuite/gcc.target/aarch64/simd/pr67896.C | 7 +++
2 files changed, 12 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index bd7a8dd..edacf10 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -610,14 +610,16 @@ aarch64_init_simd_builtin_types (void)
enum machine_mode mode = aarch64_simd_types[i].mode;
if (aarch64_simd_types[i].itype == NULL)
- aarch64_simd_types[i].itype =
- build_distinct_type_copy
+ {
+ aarch64_simd_types[i].itype =
+ build_distinct_type_copy
(build_vector_type (eltype, GET_MODE_NUNITS (mode)));
+ SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
+ }
tdecl = add_builtin_type (aarch64_simd_types[i].name,
aarch64_simd_types[i].itype);
TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
- SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
}
#define AARCH64_BUILD_SIGNED_TYPE(mode) \
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
new file mode 100644
index 000..1f916e0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
@@ -0,0 +1,7 @@
+typedef __Poly8_t A;
+typedef __Poly16_t A; /* { dg-error "conflicting declaration" } */
+typedef __Poly64_t A; /* { dg-error "conflicting declaration" } */
+typedef __Poly128_t A; /* { dg-error "conflicting declaration" } */
+
+typedef __Poly8x8_t B;
+typedef __Poly16x8_t B; /* { dg-error "conflicting declaration" } */
--
2.1.4
Issue with __int128 in powerpc64le
Hi,
I'm observing a weird behaviour in PowerPC64 Little Endian that does
not seem to occur on other architectures supporting __int128. The
following code, when compiled with -O1 generates wrong output.
-- test.c
#include stdio.h
typedef unsigned __int128 uint128_t;
#define PRINT(value) \
{ union u { uint128_t i; unsigned long long l[2]; } _t = { .i = value }; \
fprintf(stderr, %s = %016llx, %016llx\n, #value, _t.l[1],
_t.l[0]); }
__attribute__((noinline))
uint128_t get_int(uint128_t value, unsigned int num_bytes)
{
uint128_t mask = ~(uint128_t)0;
mask = (uint128_t)(8 * num_bytes); /* assuming 1 byte = 8 bits */
mask = ~mask;
value = mask;
return value;
}
int main(int argc, char* argv[])
{
uint128_t x = 0;
x = get_int(10, /* num_bytes */ 1);
PRINT(x);
return 0;
}
-- end of test.c
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/Computational/rferrer/gcc/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/Computational/rferrer/gcc/install/libexec/gcc/powerpc64le-unknown-linux-gnu/5.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-src/configure
--prefix=/home/Computational/rferrer/gcc/install
--enable-languages=c,c++,fortran
--with-gmp=/home/Computational/rferrer/gcc/install
--with-mpfr=/home/Computational/rferrer/gcc/install
--with-mpc=/home/Computational/rferrer/gcc/install --enable-multiarch
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141218 (experimental) (GCC)
$ make
gcc -O0 -o test.O0 test.c
./test.O0
x = , 000a
gcc -O1 -o test.O1 test.c
./test.O1
x = , ff00
It looks like GCC somehow forgets to perform the logical not in the
optimized version.
I'd fill a PR but I'm not sure if I'm triggering some sort of
undefined behaviour in the shift/not/and sequence in 'get_int'.
Is this a bug in GCC or in the code above?
Kind regards,
--
Roger Ferrer Ibáñez
Re: Issue with __int128 in powerpc64le
Done, it is PR64358.
Kind regards,
2014-12-19 12:21 GMT+01:00 Richard Biener richard.guent...@gmail.com:
On Fri, Dec 19, 2014 at 10:13 AM, Roger Ferrer Ibáñez
rofir...@gmail.com wrote:
Hi,
I'm observing a weird behaviour in PowerPC64 Little Endian that does
not seem to occur on other architectures supporting __int128. The
following code, when compiled with -O1 generates wrong output.
-- test.c
#include stdio.h
typedef unsigned __int128 uint128_t;
#define PRINT(value) \
{ union u { uint128_t i; unsigned long long l[2]; } _t = { .i = value };
\
fprintf(stderr, %s = %016llx, %016llx\n, #value, _t.l[1],
_t.l[0]); }
__attribute__((noinline))
uint128_t get_int(uint128_t value, unsigned int num_bytes)
{
uint128_t mask = ~(uint128_t)0;
mask = (uint128_t)(8 * num_bytes); /* assuming 1 byte = 8 bits */
mask = ~mask;
value = mask;
return value;
}
int main(int argc, char* argv[])
{
uint128_t x = 0;
x = get_int(10, /* num_bytes */ 1);
PRINT(x);
return 0;
}
-- end of test.c
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/Computational/rferrer/gcc/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/Computational/rferrer/gcc/install/libexec/gcc/powerpc64le-unknown-linux-gnu/5.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-src/configure
--prefix=/home/Computational/rferrer/gcc/install
--enable-languages=c,c++,fortran
--with-gmp=/home/Computational/rferrer/gcc/install
--with-mpfr=/home/Computational/rferrer/gcc/install
--with-mpc=/home/Computational/rferrer/gcc/install --enable-multiarch
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141218 (experimental) (GCC)
$ make
gcc -O0 -o test.O0 test.c
./test.O0
x = , 000a
gcc -O1 -o test.O1 test.c
./test.O1
x = , ff00
It looks like GCC somehow forgets to perform the logical not in the
optimized version.
I'd fill a PR but I'm not sure if I'm triggering some sort of
undefined behaviour in the shift/not/and sequence in 'get_int'.
Is this a bug in GCC or in the code above?
Please open a bug in either case.
Richard.
Kind regards,
--
Roger Ferrer Ibáñez
--
Roger Ferrer Ibáñez
ICE with nontype template parameter
Hi,
this code
---
template typename _T
struct A
{
template int _N, int _M
struct B;
template int _N
struct B_N, _T::m
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
AC::B1, 4::f();
}
--
causes the following ICE as of 4.2
[g++ 4.4]
test.cc: In function ‘void m()’:
test.cc:22: internal compiler error: in unify, at cp/pt.c:14081
g++ 4.1 yields this error, instead
[g++ 4.1]
test.cc: In function ‘void m()’:
test.cc:22: error: incomplete type ‘AC::B1, 4’ used in nested name specifier
This code seems fine to me (and so seems to intel, xlc++ and comeau online) so
I assume it is some issue in g++.
Is this a known bug or I should fill a PR?
(It seems that GCC's bugzilla has some issues at the moment of writing this
message)
Kind regards,
--
Roger Ferrer Ibáñez - roger.fer...@bsc.es
