Re: [PATCH] Fortran: check POS and LEN arguments simplifying bit intrinsics [PR105986]
Hi Harald, we need to check the POS (and LEN) arguments of bit intrinsics when simplifying, e.g. when used in array constructors. Otherwise we ICE. Found by Gerhard. The fix is straightforward, see attached. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch! Regards Thomas
Re: [PATCH] libgo: Recognize off64_t / loff_t type definition of musl libc
On Jun 18 2022, Ian Lance Taylor wrote: > What target? aarch64-suse-linux, of course. > What is the output of > > grep loff_t TARGET/libgo/gen-sysinfo.go type ___loff_t int64 type _loff_t int64 type ___kernel_loff_t int64 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] libgo: Recognize off64_t / loff_t type definition of musl libc
On Sat, Jun 18, 2022 at 12:19 AM Andreas Schwab wrote: > > ../../../libgo/go/syscall/libcall_linux.go:220:25: error: reference to > undefined name '_libgo_loff_t_type' > 220 | lroff = _libgo_loff_t_type(*roff) > | ^ > ../../../libgo/go/syscall/libcall_linux.go:226:25: error: reference to > undefined name '_libgo_loff_t_type' > 226 | lwoff = _libgo_loff_t_type(*woff) > | ^ > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > 217 | var lroff _libgo_loff_t_type > | ^ > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined > type '_libgo_loff_t_type' > make[4]: *** [Makefile:3038: syscall.lo] Error 1 > > From config.log: > > configure:15552: checking for loff_t > configure:15552: /opt/gcc/gcc-20220618/Build/./gcc/xgcc > -B/opt/gcc/gcc-20220618/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ > -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include > -isystem /usr/aarch64-suse-linux/sys-include-c -D_GNU_SOURCE > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g conftest.c >&5 > conftest.c: In function 'main': > conftest.c:104:13: error: 'loff_t' undeclared (first use in this function); > did you mean 'off_t'? > 104 | if (sizeof (loff_t)) > | ^~ > | off_t > conftest.c:104:13: note: each undeclared identifier is reported only once for > each function it appears in > configure:15552: $? = 1 What target? What is the output of grep loff_t TARGET/libgo/gen-sysinfo.go ? Thanks. Ian
Re: [PATCH] c: Handle initializations of opaque types [PR106016]
Hi Peter, On Fri, Jun 17, 2022 at 11:50:35PM -0500, Peter Bergner wrote: > The initial commit that added opaque types thought that there couldn't > be any valid initializations for variables of these types, but the test > case in the bug report shows that isn't true. The solution is to handle > OPAQUE_TYPE initializations just like the other scalar types. > > This passed bootstrap and regtesting with no regressions on powerpc64le-linux. > Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release > branches after some burn-in on trunk? > > Peter > > gcc/ > PR c/106016 > * expr.cc (count_type_elements): Handle OPAQUE_TYPE. > > gcc/testsuite/ > PR c/106016 > * gcc.target/powerpc/pr106016.c: New test. The testcase is fine everywhere. Thanks! Segher
Re: [PATCH]middle-end Add optimized float addsub without needing VEC_PERM_EXPR.
> Am 17.06.2022 um 22:34 schrieb Andrew Pinski via Gcc-patches
> :
>
> On Thu, Jun 16, 2022 at 3:59 AM Tamar Christina via Gcc-patches
> wrote:
>>
>> Hi All,
>>
>> For IEEE 754 floating point formats we can replace a sequence of alternative
>> +/- with fneg of a wider type followed by an fadd. This eliminated the need
>> for
>> using a permutation. This patch adds a math.pd rule to recognize and do this
>> rewriting.
>
> I don't think this is correct. You don't check the format of the
> floating point to make sure this is valid (e.g. REAL_MODE_FORMAT's
> signbit_rw/signbit_ro field).
> Also would just be better if you do the xor in integer mode (using
> signbit_rw field for the correct bit)?
> And then making sure the target optimizes the xor to the neg
> instruction when needed?
I’m also worried about using FP operations for the negate here. When @1 is
constant do we still constant fold this correctly?
For costing purposes it would be nice to make this visible to the vectorizer.
Also is this really good for all targets? Can there be issues with
reformatting when using FP ops as in your patch or with using integer XOR as
suggested making this more expensive than the blend?
Richard.
> Thanks,
> Andrew Pinski
>
>
>
>>
>> For
>>
>> void f (float *restrict a, float *restrict b, float *res, int n)
>> {
>> for (int i = 0; i < (n & -4); i+=2)
>>{
>> res[i+0] = a[i+0] + b[i+0];
>> res[i+1] = a[i+1] - b[i+1];
>>}
>> }
>>
>> we generate:
>>
>> .L3:
>>ldr q1, [x1, x3]
>>ldr q0, [x0, x3]
>>fnegv1.2d, v1.2d
>>faddv0.4s, v0.4s, v1.4s
>>str q0, [x2, x3]
>>add x3, x3, 16
>>cmp x3, x4
>>bne .L3
>>
>> now instead of:
>>
>> .L3:
>>ldr q1, [x0, x3]
>>ldr q2, [x1, x3]
>>faddv0.4s, v1.4s, v2.4s
>>fsubv1.4s, v1.4s, v2.4s
>>tbl v0.16b, {v0.16b - v1.16b}, v3.16b
>>str q0, [x2, x3]
>>add x3, x3, 16
>>cmp x3, x4
>>bne .L3
>>
>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>>
>> Thanks to George Steed for the idea.
>>
>> Ok for master?
>>
>> Thanks,
>> Tamar
>>
>> gcc/ChangeLog:
>>
>>* match.pd: Add fneg/fadd rule.
>>
>> gcc/testsuite/ChangeLog:
>>
>>* gcc.target/aarch64/simd/addsub_1.c: New test.
>>* gcc.target/aarch64/sve/addsub_1.c: New test.
>>
>> --- inline copy of patch --
>> diff --git a/gcc/match.pd b/gcc/match.pd
>> index
>> 51b0a1b562409af535e53828a10c30b8a3e1ae2e..af1c98d4a2831f38258d6fc1bbe811c8ee6c7c6e
>> 100644
>> --- a/gcc/match.pd
>> +++ b/gcc/match.pd
>> @@ -7612,6 +7612,49 @@ and,
>> (simplify (reduc (op @0 VECTOR_CST@1))
>> (op (reduc:type @0) (reduc:type @1
>>
>> +/* Simplify vector floating point operations of alternating sub/add pairs
>> + into using an fneg of a wider element type followed by a normal add.
>> + under IEEE 754 the fneg of the wider type will negate every even entry
>> + and when doing an add we get a sub of the even and add of every odd
>> + elements. */
>> +(simplify
>> + (vec_perm (plus:c @0 @1) (minus @0 @1) VECTOR_CST@2)
>> + (if (!VECTOR_INTEGER_TYPE_P (type) && !BYTES_BIG_ENDIAN)
>> + (with
>> + {
>> + /* Build a vector of integers from the tree mask. */
>> + vec_perm_builder builder;
>> + if (!tree_to_vec_perm_builder (&builder, @2))
>> + return NULL_TREE;
>> +
>> + /* Create a vec_perm_indices for the integer vector. */
>> + poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
>> + vec_perm_indices sel (builder, 2, nelts);
>> + }
>> + (if (sel.series_p (0, 2, 0, 2))
>> +(with
>> + {
>> + machine_mode vec_mode = TYPE_MODE (type);
>> + auto elem_mode = GET_MODE_INNER (vec_mode);
>> + auto nunits = exact_div (GET_MODE_NUNITS (vec_mode), 2);
>> + tree stype;
>> + switch (elem_mode)
>> +{
>> +case E_HFmode:
>> + stype = float_type_node;
>> + break;
>> +case E_SFmode:
>> + stype = double_type_node;
>> + break;
>> +default:
>> + return NULL_TREE;
>> +}
>> + tree ntype = build_vector_type (stype, nunits);
>> + if (!ntype)
>> +return NULL_TREE;
>> + }
>> + (plus (view_convert:type (negate (view_convert:ntype @1))) @0))
>> +
>> (simplify
>> (vec_perm @0 @1 VECTOR_CST@2)
>> (with
>> diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_1.c
>> b/gcc/testsuite/gcc.target/aarch64/simd/addsub_1.c
>> new file mode 100644
>> index
>> ..1fb91a34c421bbd2894faa0dbbf1b47ad43310c4
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_1.c
>> @@ -0,0 +1,56 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
>> +/* { dg-options "-Ofast" } */
>> +/* { dg-add-options arm_v8_2a_fp16_neon } */
>> +/
Re: [PATCH] libgo: Recognize off64_t / loff_t type definition of musl libc
../../../libgo/go/syscall/libcall_linux.go:220:25: error: reference to undefined name '_libgo_loff_t_type' 220 | lroff = _libgo_loff_t_type(*roff) | ^ ../../../libgo/go/syscall/libcall_linux.go:226:25: error: reference to undefined name '_libgo_loff_t_type' 226 | lwoff = _libgo_loff_t_type(*woff) | ^ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' 217 | var lroff _libgo_loff_t_type | ^ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type '_libgo_loff_t_type' make[4]: *** [Makefile:3038: syscall.lo] Error 1 >From config.log: configure:15552: checking for loff_t configure:15552: /opt/gcc/gcc-20220618/Build/./gcc/xgcc -B/opt/gcc/gcc-20220618/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include-c -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g conftest.c >&5 conftest.c: In function 'main': conftest.c:104:13: error: 'loff_t' undeclared (first use in this function); did you mean 'off_t'? 104 | if (sizeof (loff_t)) | ^~ | off_t conftest.c:104:13: note: each undeclared identifier is reported only once for each function it appears in configure:15552: $? = 1 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
