Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

Neither K nor J is an extension that exists, and so it doesn't make sense to mandate any particular ordering. The better change would be to delete the letters `k' and `j' from that string, so that we aren't enforcing constraints that don't serve a useful purpose. cf.

[PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

This commit fixes canonical extension order to follow the RISC-V ISA Manual draft-20210402-1271737 or later. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_supported_std_ext): Fix "K" extension prefix to be placed before "J". ---

[PATCH 0/1] RISC-V: Fix canonical extension order (K and J)

**note** My copyright assignment to FSF is not yet started (will start just after sending this patch). Please take care of the assignment status. This patch fixes RISC-V's canonical extension order... from: "J" -> "K" to : "K" -> "J" as per the RISC-V ISA Manual draft-20210402-1271737 or

Re: [PATCH] AVX512F: Add missing macro for mask(z?)_scalf_s[sd] [PR 105339]

On Fri, Apr 22, 2022 at 8:43 PM Hongyu Wang wrote: > > > Please add the corresponding intrinsic test in sse-14.c > > Sorry for forgetting this part. Updated patch. Thanks. > LGTM. > Hongtao Liu via Gcc-patches 于2022年4月22日周五 16:49写道： > > > > On Fri, Apr 22, 2022 at 4:12 PM Hongyu Wang via

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

Yes, Thank you Mikael! On 4/22/22 6:59 AM, Thomas Koenig via Fortran wrote: Hi Mikael, Ping for the four patches starting at https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html : https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html

[PATCH v1] RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZERO

The Zbb support has introduced ctz and clz to the backend, but some transformations in GCC need to know what the value of c[lt]z at zero is. This affects how the optab is generated and may suppress use of CLZ/CTZ in tree passes. Among other things, this is needed for the transformation of

Re: [PATCH v2] fortran: Detect duplicate unlimited polymorphic types [PR103662]

Hi Mikael, Am 22.04.22 um 12:53 schrieb Mikael Morin: Le 21/04/2022 à 23:14, Mikael Morin a écrit : Hello, this is a fix for PR103662, a TBAA issue with unlimited polymorphic types. I attached a draft patch to the PR which was accumulating all unlimited polymorphic symbols to a single

Re: [PATCH] PR target/89125

ping. On Fri, Apr 15, 2022 at 09:23:43AM -0700, Steve Kargl wrote: > Can someone, anyone, please commit the attach patch, which is > also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 > where one can read the audit trail. The original patch was > submitted 2 years ago, and

[PATCH] ppc: testsuite: float128-hw{,4}.c need -mlong-double-128 (was: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128)

On Apr 14, 2022, Alexandre Oliva wrote: > * gcc.target/powerpr/pr79004.c: Add -mlong-double-128. Just like pr79004, float128-hw.c requires -mlong-double-128 for some the expected asm opcodes to be output on target variants that have 64-bit long doubles. That's because their expanders,

Re: [PATCH] i386: Improve ix86_expand_int_movcc [PR105338]

On Sat, Apr 23, 2022 at 8:53 AM Jakub Jelinek wrote: > > Hi! > > The following testcase regressed on x86_64 on the trunk, due to some GIMPLE > pass changes (r12-7687) we end up an *.optimized dump difference of: > @@ -8,14 +8,14 @@ int foo (int i) > > [local count: 1073741824]: >if

Re: [PATCH] c++: __builtin_shufflevector with value-dep expr [PR105353]

On Fri, Apr 22, 2022 at 07:57:34PM -0400, Marek Polacek via Gcc-patches wrote: > Here we issue an error from c_build_shufflevector while parsing a template > because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs > (except the first two arguments). It checks if any of the

[PATCH] i386: Improve ix86_expand_int_movcc [PR105338]

Hi! The following testcase regressed on x86_64 on the trunk, due to some GIMPLE pass changes (r12-7687) we end up an *.optimized dump difference of: @@ -8,14 +8,14 @@ int foo (int i) [local count: 1073741824]: if (i_2(D) != 0) -goto ; [35.00%] +goto ; [35.00%] else -goto ;

Re: [PATCH] c++: __builtin_shufflevector with value-dep expr [PR105353]

> Am 23.04.2022 um 01:58 schrieb Marek Polacek via Gcc-patches > : > > Here we issue an error from c_build_shufflevector while parsing a template > because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs > (except the first two arguments). It checks if any of the